OLTPシナリオの性能チューニングの実践

TiDB は、TiDB ダッシュボードのTop SQLと継続的なプロファイリング機能や、TiDB パフォーマンス概要ダッシュボードの包括的なパフォーマンス診断および分析機能を提供します。

このドキュメントでは、これらの機能を組み合わせて使用し、7 つの異なるランタイム シナリオで同じ OLTP ワークロードのパフォーマンスを分析および比較する方法について説明します。これにより、TiDB のパフォーマンスを効率的に分析および調整するのに役立つパフォーマンス チューニング プロセスが示されます。

注記：

Top SQLと継続的なプロファイリングデフォルトでは有効になっていません。事前に有効にする必要があります。

このドキュメントでは、これらのシナリオで同じアプリケーションを異なる JDBC 構成で実行することにより、アプリケーションとデータベース間のさまざまな相互作用が全体的なシステム パフォーマンスにどのように影響するかを示し、 TiDB を使用したJavaアプリケーション開発のベスト プラクティス適用してパフォーマンスを向上できるようにします。

環境の説明

このドキュメントでは、銀行業務のコアOLTPワークロードを例に挙げて説明します。シミュレーション環境の構成は次のとおりです。

• ワークロードのアプリケーション開発言語: JAVA
• 業務で使用されるSQL文：合計200文、そのうち90%がSELECT文です。これは典型的な読み取り中心のOLTPワークロードです。
• トランザクションで使用されるテーブル: 合計 60 テーブル。12 テーブルは更新操作に関連し、残りの 48 テーブルは読み取り専用です。
• アプリケーションで使用される分離レベル: read committed 。
• TiDB クラスター構成: 3 つの TiDB ノードと 3 つの TiKV ノード、各ノードに 16 個の CPU が割り当てられます。
• クライアントサーバー構成: 36 個の CPU。

シナリオ1. クエリインターフェースを使用する

アプリケーション構成

アプリケーションは、次の JDBC 構成を使用して、クエリ インターフェイスを介してデータベースに接続します。

useServerPrepStmts=false

パフォーマンス分析

TiDBダッシュボード

下記のTiDBダッシュボードの「Top SQL」ページを見ると、非ビジネスSQLタイプSELECT @@session.tx_isolation最も多くのリソースを消費していることがわかります。TiDBはこれらのタイプのSQL文を迅速に処理しますが、実行回数が最も多く、全体的なCPU消費量も最も高くなります。

以下のTiDBのフレームチャートから、SQL実行中にCompileやOptimizeなどの関数のCPU消費が顕著であることがわかります。アプリケーションはQueryインターフェースを使用しているため、TiDBは実行プランキャッシュを使用できません。TiDBはSQL文ごとにコンパイルして実行プランを生成する必要があります。

• ExecuteStmt CPU = 38% CPU時間 = 23.84秒
• コンパイルCPU = 27% CPU時間 = 17.17秒
• CPUを最適化 = 26%、CPU時間 = 16.41秒

パフォーマンス概要ダッシュボード

次のパフォーマンス概要ダッシュボードで、データベース時間の概要と QPS を確認します。

• SQL タイプ別のデータベース時間: Selectステートメント タイプがほとんどの時間を費やします。
• SQL フェーズ別のデータベース時間: フェーズexecuteとcompileほとんどの時間がかかります。
• SQL 実行時間の概要: Get 、およびtso wait Copの時間がかかります。
• タイプ別 CPS: Queryコマンドのみが使用されます。
• プラン キャッシュ OPS を使用したクエリ: データなしは、実行プラン キャッシュがヒットしていないことを示します。
• クエリ期間では、レイテンシーexecuteとcompile割合が最も高くなります。
• 平均QPS = 56.8k

クラスタのリソース消費量を確認すると、TiDB CPUの平均使用率は925%、TiKV CPUの平均使用率は201%、TiKV IOの平均スループットは18.7 MB/sと、TiDBのリソース消費量が大幅に高くなっています。

分析の結論

実行回数が多く、TiDB の CPU 使用率が高くなる原因となる、ビジネスには関係のない無駄な SQL ステートメントを排除する必要があります。

シナリオ2. maxPerformance構成を使用する

アプリケーション構成

シナリオ1では、アプリケーションはJDBC接続文字列に新しいパラメータuseConfigs=maxPerformanceを追加します。このパラメータを使用することで、JDBCからデータベースに送信されるSQL文（例： select @@session.transaction_read_only ）を削減できます。完全な構成は次のとおりです。

useServerPrepStmts=false&useConfigs=maxPerformance

パフォーマンス分析

TiDBダッシュボード

下記の TiDB ダッシュボードのTop SQLページを見ると、最も多くのリソースを消費していたSELECT @@session.tx_isolationが消えていることがわかります。

次の TiDB のフレーム チャートから、SQL 実行中にCompileやOptimizeの関数の CPU 消費が依然として大きいことがわかります。

• ExecuteStmt CPU = 43% CPU時間 =35.84秒
• コンパイルCPU = 31% CPU時間 = 25.61秒
• CPUを最適化 = 30% CPU時間 = 24.74秒

パフォーマンス概要ダッシュボード

データベースの時間概要と QPS のデータは次のとおりです。

• SQL タイプ別のデータベース時間: Selectステートメント タイプがほとんどの時間を費やします。
• SQL フェーズ別のデータベース時間: フェーズexecuteとcompileほとんどの時間がかかります。
• SQL 実行時間の概要: Get Prewriteおよびtso wait Copの時間を費やします。
• データベース時間では、レイテンシーexecuteとcompile割合が最も高くなります。
• タイプ別 CPS: Queryコマンドのみが使用されます。
• 平均QPS = 24.2k (56.3kから24.2k)
• 実行プラン キャッシュにヒットしません。

シナリオ 1 からシナリオ 2 にかけて、TiDB の平均 CPU 使用率は 925% から 874% に低下し、TiKV の平均 CPU 使用率は 201% から約 250% に増加します。

主要なレイテンシーメトリックの変更は次のとおりです。

• 平均クエリ時間 = 1.12ms (479μsから1.12ms)
• 平均解析時間 = 84.7μs (37.2μsから84.7μs)
• 平均コンパイル時間 = 370μs (166μsから370μs)
• 平均実行時間 = 626μs (251μsから626μs)

分析の結論

シナリオ1と比較して、シナリオ2のQPSは大幅に減少しました。平均クエリ実行時間と、 compile execute parse実行時間が大幅に増加しました。これは、シナリオ1のselect @@session.transaction_read_onlyようなSQL文は実行回数が多く、処理時間が短いため、平均パフォーマンスデータが低下したためです。シナリオ2ではこれらのSQL文がブロックされ、業務関連のSQL文のみが残るため、平均実行時間が増加します。

アプリケーションがQueryインターフェースを使用する場合、TiDBは実行プランキャッシュを使用できないため、実行プランのコンパイルに多くのリソースを消費します。このような場合は、TiDBの実行プランキャッシュを使用するPrepared Statementインターフェースの使用をお勧めします。Prepared Statementインターフェースは、実行プランのコンパイルによるTiDBのCPU消費を削減し、レイテンシーを短縮します。

シナリオ3. 実行プランのキャッシュを有効にせずにPrepared Statementインターフェースを使用する

アプリケーション構成

アプリケーションは以下の接続構成を使用します。シナリオ2と比較すると、JDBCパラメータuseServerPrepStmtsの値がtrueに変更されており、Prepared Statementインターフェースが有効になっていることを示しています。

useServerPrepStmts=true&useConfigs=maxPerformance"

パフォーマンス分析

TiDBダッシュボード

次の TiDB のフレーム チャートから、Prepared Statement インターフェイスを有効にした後でも、 CompileExecutePreparedStmtとOptimizeの CPU 消費が依然として大きいことがわかります。

• ExecutePreparedStmt CPU = 31% CPU 時間 = 23.10秒
• preparedStmtExec CPU = 30% CPU 時間 = 22.92 秒
• CompileExecutePreparedStmt CPU = 24% CPU 時間 = 17.83 秒
• CPUを最適化 = 23%、CPU時間 = 17.29秒

パフォーマンス概要ダッシュボード

Prepared Statement インターフェイスを使用した後、データベース時間の概要と QPS のデータは次のようになります。

QPSは24.4kから19.7kに低下しています。データベース時間の概要を見ると、アプリケーションが3種類のPreparedコマンドを使用しており、 generalステートメントタイプ（ StmtPrepareやStmtCloseなどのコマンドの実行時間を含む）がSQLタイプ別のデータベース時間で2番目に高い値になっていることがわかります。これは、Prepared Statementインターフェースを使用しても、実行プランキャッシュにヒットしていないことを示しています。これは、 StmtCloseコマンド実行時に、TiDBが内部処理でSQL文の実行プランキャッシュをクリアするためです。

• SQL タイプ別のデータベース時間: Selectステートメント タイプが最も時間がかかり、次にgeneralステートメントが続きます。
• SQL フェーズ別のデータベース時間: フェーズexecuteとcompileほとんどの時間がかかります。
• SQL 実行時間の概要: Get Prewriteおよびtso wait Copの時間を費やします。
• タイプ別 CPS: 3 種類のコマンド ( StmtPrepare ) StmtExecute使用さStmtCloseます。
• 平均QPS = 19.7k (24.4kから19.7k)
• 実行プラン キャッシュにヒットしません。

TiDB の平均 CPU 使用率は 874% から 936% に増加します。

主要なレイテンシーメトリックは次のとおりです。

• 平均クエリ時間 = 528μs (1.12msから528μs)
• 平均解析時間 = 14.9μs (84.7μsから14.9μs)
• 平均コンパイル時間 = 374μs (370μsから374μs)
• 平均実行時間 = 649μs (626μsから649μs)

分析の結論

シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ Query ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ StmtPrepare ）多くあります。シナリオ2と比較すると、シナリオ3ではネットワークのラウンドトリップ遅延StmtExecute 2 StmtClose多くなっています。

• QPS の減少に関する分析： 「CPS By Type」ペインを見ると、シナリオ 2 には「CPS By Type」コマンドタイプが 1 つ ( Query ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( StmtPrepare ) StmtExecute存在することがわかります。11 とStmtClose StmtPrepare QPS にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来StmtCloseコマンドのStmtPrepareとStmtClose general SQL タイプにカウントされるため、シナリオ 3 のデータベース概要にはgeneral時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。
• 平均クエリ時間が大幅に短縮された理由の分析：シナリオ3で新たに追加されたコマンドタイプStmtPrepareとStmtCloseについては、TiDB内部処理でクエリ時間が個別に計算されます。TiDBはこれらの2種類のコマンドを非常に高速に実行するため、平均クエリ時間が大幅に短縮されます。

シナリオ3ではPrepared Statementインターフェースを使用していますが、多くのアプリケーションフレームワークがメモリリークを防ぐためにメソッドStmtExecute後にメソッドStmtClose呼び出すため、実行プランのキャッシュは依然としてアクセスされません。v6.0.0以降では、グローバル変数tidb_ignore_prepared_cache_close_stmt=on;設定できます。これにより、アプリケーションがメソッドStmtCloseを呼び出しても、TiDBはキャッシュされた実行プランをクリアしなくなります。そのため、次のSQL実行では既存の実行プランを再利用でき、実行プランの重複コンパイルを回避できます。

シナリオ4. Prepared Statement インターフェースを使用して実行プランのキャッシュを有効にする

アプリケーション構成

アプリケーションの構成はシナリオ 3 と同じままです。アプリケーションがStmtCloseトリガーしてもキャッシュにヒットしない問題を解決するために、次のパラメータが構成されています。

• TiDB グローバル変数set global tidb_ignore_prepared_cache_close_stmt=on;設定します (TiDB v6.0.0 以降に導入、デフォルトはoff )。
• プラン キャッシュ機能を有効にするには、TiDB 構成項目prepared-plan-cache: {enabled: true}設定します。

パフォーマンス分析

TiDBダッシュボード

TiDB CPU 使用率のフレーム チャートから、 CompileExecutePreparedStmtとOptimize CPU 消費量が大幅に増加していないことがわかります。CPU の 25% は、 PlanBuilderやparseSQLなどの Prepare の解析関連の関数を含むPrepareコマンドによって消費されています。

PreparseStmt CPU = 25% CPU 時間 = 12.75 秒

パフォーマンス概要ダッシュボード

パフォーマンス概要ダッシュボードで最も顕著な変化は、フェーズcompileの平均時間です。シナリオ3の8.95秒/秒から1.18秒/秒に短縮されています。実行プランキャッシュを使用するクエリの数は、 StmtExecuteの値とほぼ等しくなります。QPSの増加に伴い、1秒あたりSelectステートメントのデータベース消費時間は減少し、1秒あたりgeneralステートメントのデータベース消費時間は増加しています。

• SQL タイプ別のデータベース時間: Selectのステートメント タイプが最も時間がかかります。
• SQL フェーズ別のデータベース時間: フェーズexecuteがほとんどの時間を費やします。
• SQL 実行時間の概要: tso wait 、およびCop Getの時間がかかります。
• 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約StmtExecuteです。
• タイプ別CPS: 3種類のコマンド（シナリオ3と同じ）
• シナリオ 3 と比較すると、QPS が増加したため、 generalステートメントで消費される時間が長くなります。
• 平均QPS = 22.1k (19.7kから22.1k)

平均 TiDB CPU 使用率は 936% から 827% に低下します。

平均compileあたりの処理時間は374usから53.3usへと大幅に短縮されました。QPSが上昇したため、平均executeあたりの処理時間も増加しています。

• 平均クエリ実行時間 = 426μs (528μsから426μs)
• 平均解析時間 = 12.3μs (14.8μsから12.3μs)
• 平均コンパイル時間 = 53.3μs (374μsから53.3μs)
• 平均実行時間 = 699μs (649μsから699us)

分析の結論

シナリオ3と比較すると、シナリオ4でも3種類のコマンドが使用されます。違いは、シナリオ4では実行プランキャッシュが使用されるため、コンパイル時間が大幅に短縮され、クエリ実行時間も短縮され、QPSも向上することです。

StmtPrepareとStmtCloseコマンドはデータベース処理時間を大量に消費し、アプリケーションがSQL文を実行するたびにアプリケーションとTiDB間のやり取りの回数を増加させるためです。次のシナリオでは、JDBC設定を通じてこれらの2つのコマンドの呼び出しを削減することで、パフォーマンスをさらにチューニングします。

シナリオ5. クライアント側で準備されたオブジェクトをキャッシュする

アプリケーション構成

シナリオ 4 と比較すると、以下で説明するように、3 つの新しい JDBC パラメータcachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480構成されます。

• cachePrepStmts = true : クライアント側で Prepared Statement オブジェクトをキャッシュし、StmtPrepare および StmtClose の呼び出しを排除します。
• prepStmtCacheSize : 値は 0 より大きくなければなりません。
• prepStmtCacheSqlLimit : 値は SQL テキストの長さより大きくなければなりません。

シナリオ 5 では、完全な JDBC 構成は次のようになります。

useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480&useConfigs=maxPerformance

パフォーマンス分析

TiDBダッシュボード

次の TiDB のフレーム チャートから、コマンドPrepareの高い CPU 消費がなくなったことがわかります。

• ExecutePreparedStmt CPU = 22% CPU 時間 = 8.4 秒

パフォーマンス概要ダッシュボード

パフォーマンス概要ダッシュボードで最も注目すべき変更点は、 CPS By Typeペインの 3 つの Stmt コマンド タイプが 1 つに減り、 Database Time by SQL Typeペインのgeneralステートメント タイプが消え、 QPSペインの QPS が 30.9k に増加したことです。

• SQL タイプ別のデータベース時間: Selectステートメント タイプが最も多くの時間を費やし、 generalステートメント タイプは消えます。
• SQL フェーズ別のデータベース時間: フェーズexecuteがほとんどの時間を費やします。
• SQL 実行時間の概要: tso wait 、およびCop Getの時間がかかります。
• 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約StmtExecuteです。
• タイプ別 CPS: StmtExecuteコマンドのみが使用されます。
• 平均QPS = 30.9k (22.1kから30.9k)

TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加すると、TiKVの平均CPU使用率は313%に増加しました。

主要なレイテンシーメトリックは次のとおりです。

• 平均クエリ期間 = 690μs (426μsから690μs)
• 平均解析時間 = 13.5μs (12.3μsから13.5μs)
• 平均コンパイル時間 = 49.7μs (53.3μsから49.7μs)
• 平均実行時間 = 623μs (699us から 623μs)
• 平均 pd tso 待機時間 = 196μs (224μs から 196μs)
• 接続アイドル時間 avg-in-txn = 608μs (250μsから608μs)

分析の結論

• シナリオ 4 と比較すると、シナリオ 5 のCPS By TypeペインにはStmtExecuteコマンドのみがあり、これにより 2 回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。
• QPSが増加すると、解析時間、コンパイル時間、実行時間という点でレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBがStmtPrepareとStmtClose非常に高速に処理するため、これらの2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。
• SQLフェーズ別データベース時間では、 execute最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 tso wait最も時間がかかり、 executeの4分の1以上がTSOの待機に費やされています。
• 1秒あたりtso waitの実行時間は合計5.46秒です。3 tso wait実行時間の平均は196マイクロ秒、1秒あたりtso cmd回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベルread committedの実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。

TiDB v6.0 はrc read提供します。これはtso cmd削減することでread committed分離レベルを最適化します。この機能はグローバル変数set global tidb_rc_read_check_ts=on;によって制御されます。この変数を有効にすると、TiDB のデフォルトの動作はrepeatable-read分離レベルと同じように動作し、PD から取得する必要があるのはstart-tsとcommit-tsです。トランザクション内のステートメントは、最初にstart-ts使用して TiKV からデータを読み取ります。TiKV から読み取られたデータがstart-tsより前の場合、データは直接返されます。TiKV から読み取られたデータがstart-tsより後の場合、データは破棄されます。TiDB は PD から TSO を要求し、読み取りを再試行します。後続のステートメントのfor update tsでは、最新の PD TSO が使用されます。

シナリオ6: tidb_rc_read_check_ts変数を有効にしてTSOリクエストを削減する

アプリケーション構成

シナリオ5と比較すると、アプリケーション構成は同じです。唯一の違いは、変数set global tidb_rc_read_check_ts=on;がTSOリクエストを削減するように設定されていることです。

パフォーマンス分析

ダッシュボード

TiDB CPU のフレーム チャートには大きな変化はありません。

• ExecutePreparedStmt CPU = 22% CPU 時間 = 8.4秒

パフォーマンス概要ダッシュボード

RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 tso wait秒あたりの消費時間は 5.46 秒から 456 ミリ秒に減少します。

• SQL タイプ別のデータベース時間: Selectステートメント タイプがほとんどの時間を費やします。
• SQL フェーズ別のデータベース時間: フェーズexecuteがほとんどの時間を費やします。
• SQL 実行時間の概要: Get 、およびPrewrite Copの時間がかかります。
• 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約StmtExecuteです。
• タイプ別 CPS: StmtExecuteコマンドのみが使用されます。
• 平均QPS = 34.9k (30.9kから34.9k)

tso cmd秒あたり1は28.3kから2.7kに減少します。

平均 TiDB CPU は 603% に増加します (577% から 603%)。

主要なレイテンシーメトリックは次のとおりです。

• 平均クエリ実行時間 = 533μs (690μsから533μs)
• 平均解析時間 = 13.4μs (13.5μsから13.4μs)
• 平均コンパイル時間 = 50.3μs (49.7μsから50.3μs)
• 平均実行時間 = 466μs (623μsから466μs)
• 平均 pd tso 待機時間 = 171μs (196μs から 171μs)

分析の結論

RC Read をset global tidb_rc_read_check_ts=on;有効にした後、RC Read によってtso cmd時間が大幅に短縮され、 tso waitと平均クエリ期間が短縮され、QPS が向上しました。

現在のデータベース時間とレイテンシーの両方のボトルネックは、フェーズexecuteにあります。このフェーズでは、 GetとCop読み取りリクエストが最も高い割合を占めています。このワークロードのテーブルのほとんどは読み取り専用か、ほとんど変更されないため、TiDB v6.0.0以降でサポートされている小さなテーブルのキャッシュ機能を使用して、これらの小さなテーブルのデータをキャッシュすることで、KV読み取りリクエストの待機時間とリソース消費を削減できます。

シナリオ7: 小さなテーブルキャッシュを使用する

アプリケーション構成

シナリオ6と比較して、アプリケーション構成は同じです。唯一の違いは、シナリオ7では、ビジネス用の読み取り専用テーブルをキャッシュするために、 alter table t1 cache;ようなSQL文を使用する点です。

パフォーマンス分析

TiDBダッシュボード

TiDB CPU のフレーム チャートには大きな変化はありません。

パフォーマンス概要ダッシュボード

QPSは34.9kから40.9kに増加し、KVリクエストタイプはフェーズexecuteからフェーズPrewriteとCommitへの変更で最も時間がかかります。1秒あたりGetのデータベース消費時間は5.33秒から1.75秒に短縮され、1秒あたりCopのデータベース消費時間は3.87秒から1.09秒に短縮されます。

• SQL タイプ別のデータベース時間: Selectステートメント タイプがほとんどの時間を費やします。
• SQL フェーズ別のデータベース時間: フェーズexecuteとcompileほとんどの時間がかかります。
• SQL 実行時間の概要: Prewrite 、およびGet Commitの時間がかかります。
• 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約StmtExecuteです。
• タイプ別 CPS: StmtExecuteコマンドのみが使用されます。
• 平均QPS = 40.9k (34.9kから40.9k)

平均 TiDB CPU 使用率は 603% から 478% に低下し、平均 TiKV CPU 使用率は 346% から 256% に低下します。

平均クエリレイテンシーは533usから313usに短縮されました。平均executeレイテンシーは466usから250usに短縮されました。

• 平均クエリ期間 = 313μs (533μsから313μs)
• 平均解析時間 = 11.9μs (13.4μsから11.9μs)
• 平均コンパイル時間 = 47.7μs (50.3μsから47.7μs)
• 平均実行時間 = 251μs (466μsから251μs)

分析の結論

すべての読み取り専用テーブルをキャッシュした後、 Execute Duration大幅に低下します。これは、すべての読み取り専用テーブルが TiDB にキャッシュされ、それらのテーブルに対して TiKV でデータをクエリする必要がないため、クエリ期間が短縮され、QPS が増加するためです。

これは楽観的結果です。実際の業務では、読み取り専用テーブルのデータはTiDBがすべてをキャッシュするには大きすぎる可能性があります。また、小さなテーブルのキャッシュ機能は書き込み操作をサポートしますが、書き込み操作にはデフォルトで3秒間の待機時間が必要であり、これはすべてのTiDBノードのキャッシュが無効化されることを保証するためです。これは、レイテンシー要件が厳しいアプリケーションには適さない可能性があります。

まとめ

次の表は、7 つの異なるシナリオのパフォーマンスを示しています。

これらのシナリオでは、シナリオ 2 はアプリケーションがクエリ インターフェイスを使用する一般的なシナリオであり、シナリオ 5 はアプリケーションが準備済みステートメント インターフェイスを使用する理想的なシナリオです。

• シナリオ 5 とシナリオ 2 を比較すると、 Javaアプリケーション開発のベスト プラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすると、各 SQL ステートメントで実行プラン キャッシュをヒットするために必要なコマンドとデータベース操作が 1 つだけになり、クエリのレイテンシーが 38% 減少し、QPS が 28% 増加する一方で、TiDB の CPU 使用率の平均が 936% から 577% に減少することがわかります。
• シナリオ 7 とシナリオ 3 を比較すると、シナリオ 5 に RC 読み取りや小さなテーブル キャッシュなどの最新の TiDB 最適化機能を追加すると、レイテンシーが 41% 削減され、QPS が 108% 増加し、平均 TiDB CPU 使用率が 936% から 478% に低下することがわかります。

各シナリオのパフォーマンスを比較すると、次のような結論を導き出すことができます。

• TiDBの実行計画キャッシュは、OLTPパフォーマンスチューニングにおいて重要な役割を果たします。バージョン6.0.0から導入されたRC Read機能とスモールテーブルキャッシュ機能も、このワークロードのさらなるパフォーマンスチューニングにおいて重要な役割を果たします。

• TiDBはMySQLプロトコルの様々なコマンドと互換性があります。Prepared Statementインターフェースを使用し、以下のJDBC接続パラメータを設定することで、アプリケーションは最高のパフォーマンスを実現できます。

  useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480&useConfigs=maxPerformance
  

• パフォーマンス分析とチューニングには、TiDB ダッシュボード (たとえば、Top SQL機能や継続的なプロファイリング機能) とパフォーマンス概要ダッシュボードを使用することをお勧めします。

  • Top SQL機能を使用すると、実行中にデータベース内の各 SQL ステートメントの CPU 消費量を視覚的に監視および調査して、データベースのパフォーマンスの問題をトラブルシューティングできます。
  • 継続的なプロファイリング使用すると、TiDB、TiKV、PD の各インスタンスからパフォーマンスデータを継続的に収集できます。アプリケーションが TiDB とやり取りするために異なるインターフェースを使用する場合、TiDB の CPU 消費量に大きな差が生じます。
  • パフォーマンス概要ダッシュボードを使用すると、データベース時間とSQL実行時間の内訳情報の概要を取得できます。データベース時間に基づいてパフォーマンスを分析・診断することで、システム全体のパフォーマンスボトルネックがTiDBにあるかどうかを判断できます。ボトルネックがTiDBにある場合は、データベース時間とレイテンシーの内訳、負荷プロファイル、リソース使用率に基づいて、TiDB内のパフォーマンスボトルネックを特定し、それに応じてパフォーマンスを調整できます。

これらの機能を組み合わせて使用することで、実際のアプリケーションのパフォーマンスを効率的に分析および調整できます。