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 ステートメントを迅速に処理しますが、これらのタイプの 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、およびCoptso waitほとんどの時間がかかります。 - タイプ別 CPS:
Queryコマンドのみが使用されます。 - プラン キャッシュ OPS を使用したクエリ: データなしは、実行プラン キャッシュがヒットしていないことを示します。
- クエリ期間では、レイテンシー
executeとcompileの割合が最も高くなります。 - 平均 QPS = 56.8k
クラスターのリソース消費量を確認します。TiDB CPU の平均使用率は 925%、TiKV CPU の平均使用率は 201%、TiKV IO の平均スループットは 18.7 MB/秒です。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 実行時間
Cop概要:GetPrewriteおよびtso waitほとんどの時間がかかります。 - データベース時間では、レイテンシー
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 は大幅に減少しています。平均クエリ期間と平均parse 、 compile 、 execute期間は大幅に増加しています。これは、シナリオ 1 のselect @@session.transaction_read_onlyなどの実行回数が多く、処理時間が速い SQL 文が平均パフォーマンス データを下げるためです。シナリオ 2 でこのような文がブロックされると、ビジネス関連の SQL 文のみが残るため、平均期間が増加します。
アプリケーションがクエリ インターフェイスを使用する場合、TiDB は実行プラン キャッシュを使用できないため、実行プランをコンパイルするために TiDB が大量のリソースを消費することになります。この場合、TiDB の実行プラン キャッシュを使用して実行プランのコンパイルによる TiDB CPU 消費を減らし、レイテンシーを短縮する Prepared Statement インターフェイスを使用することをお勧めします。
シナリオ 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 に低下しています。Database Time Overview から、アプリケーションが 3 種類の Prepared コマンドを使用しており、 generalステートメント タイプ ( StmtPrepareやStmtCloseなどのコマンドの実行時間を含む) が Database Time by SQL Type で 2 位になっていることがわかります。これは、Prepared Statement インターフェイスを使用しても、実行プラン キャッシュにヒットしないことを示しています。これは、 StmtCloseコマンドを実行すると、TiDB が内部処理で SQL ステートメントの実行プラン キャッシュをクリアするためです。
- SQL タイプ別のデータベース時間:
Selectステートメント タイプが最も時間がかかり、次にgeneralステートメント タイプが続きます。 - SQL フェーズ別のデータベース時間: フェーズ
executeとcompileがほとんどの時間を費やします。 - SQL 実行時間
Cop概要:GetPrewriteおよびtso waitほとんどの時間がかかります。 - タイプ
StmtCloseCPS: 3StmtExecuteStmtPrepareが使用されます。 - 平均 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 、 StmtExecute 、 StmtClose ) 多くあります。シナリオ 2 と比較すると、シナリオ 3 にはネットワーク ラウンドトリップ遅延が 2 つ多くあります。
- QPS の減少に関する分析: CPS By Typeペインから、シナリオ 2 には CPS By Type コマンド タイプが 1 つ (
Query) しかなく、シナリオ 3 にはさらに 3 つのコマンド タイプ (StmtPrepare、StmtExecute、StmtClose) があることがわかりますStmtPrepareとStmtCloseQPS でカウントされない非従来型コマンドであるため、QPS が減少します。非従来型コマンドStmtPrepareとStmtCloseはgeneralSQL タイプにカウントされるため、シナリオ 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% はPrepareコマンドによって消費されており、これにはPlanBuilderやparseSQLなどの 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、およびGetCopほとんどの時間がかかります。 - 実行プラン キャッシュがヒットしました。プラン キャッシュ OPS を使用するクエリの値は、1 秒あたりおよそ
StmtExecute相当します。 - タイプ別CPS: 3種類のコマンド(シナリオ3と同じ)
- シナリオ 3 と比較すると、QPS が増加したため、
generalステートメントで消費される時間が長くなります。 - 平均 QPS = 22.1k (19.7k から 22.1k)
平均 TiDB CPU 使用率は 936% から 827% に低下します。
平均compile時間は 374 us から 53.3 us に大幅に減少しました。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、およびGetCopほとんどの時間がかかります。 - 実行プラン キャッシュがヒットしました。プラン キャッシュ 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 秒です。平均tso wait回は 196 us で、1 秒あたりtso cmd回の数は 28k であり、これは QPS の 30.9k に非常に近いです。これは、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、およびCopPrewriteほとんどの時間がかかります。 - 実行プラン キャッシュがヒットしました。プラン キャッシュ OPS を使用するクエリの値は、1 秒あたりおよそ
StmtExecute相当します。 - タイプ別 CPS:
StmtExecuteコマンドのみが使用されます。 - 平均 QPS = 34.9k (30.9k から 34.9k)
1 秒あたりtso cmd 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 を向上させます。
現在のデータベース時間とレイテンシーの両方のボトルネックは、 GetとCopの読み取り要求の割合が最も高いフェーズexecuteにあります。このワークロードのテーブルのほとんどは読み取り専用であるか、ほとんど変更されないため、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、およびCommitGetほとんどの時間がかかります。 - 実行プラン キャッシュがヒットしました。プラン キャッシュ OPS を使用するクエリの値は、1 秒あたりおよそ
StmtExecute相当します。 - タイプ別 CPS:
StmtExecuteコマンドのみが使用されます。 - 平均 QPS = 40.9k (34.9k から 40.9k)
平均 TiDB CPU 使用率は 603% から 478% に低下し、平均 TiKV CPU 使用率は 346% から 256% に低下します。
平均クエリレイテンシーは533 us から 313 us に短縮されます。平均executeレイテンシーは466 us から 250 us に短縮されます。
- 平均クエリ期間 = 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 がすべてをキャッシュするには大きすぎる可能性があるからです。もう 1 つの制限は、小さなテーブル キャッシュ機能は書き込み操作をサポートしますが、書き込み操作ではすべての TiDB ノードのキャッシュが最初に無効になることを保証するためにデフォルトで 3 秒の待機時間が必要であり、レイテンシー要件が厳しいアプリケーションでは実現できない可能性があることです。
まとめ
次の表は、7 つの異なるシナリオのパフォーマンスを示しています。
| メトリクス | シナリオ1 | シナリオ2 | シナリオ3 | シナリオ4 | シナリオ5 | シナリオ6 | シナリオ7 | シナリオ5とシナリオ2の比較（％） | シナリオ7とシナリオ3の比較（％） |
|---|---|---|---|---|---|---|---|---|---|
| クエリ期間 | 479μs | 1120μs | 528μs | 426μs | 690μs | 533μs | 313μs | -38% | -51% |
| 品質保証 | 56.3k | 24.2k | 19.7k | 22.1k | 30.9k | 34.9k | 40.9k | +28% | +108% |
これらのシナリオでは、シナリオ 2 はアプリケーションがクエリ インターフェイスを使用する一般的なシナリオであり、シナリオ 5 はアプリケーションが準備済みステートメント インターフェイスを使用する理想的なシナリオです。
- シナリオ 2 とシナリオ 5 を比較すると、 Javaアプリケーション開発のベスト プラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすると、各 SQL ステートメントで実行プラン キャッシュをヒットするために必要なコマンドとデータベース操作が 1 つだけになり、クエリのレイテンシーが 38% 短縮され、QPS が 28% 増加する一方で、TiDB の平均 CPU 使用率は 936% から 577% に低下することがわかります。
- シナリオ 2 とシナリオ 7 を比較すると、シナリオ 5 に RC 読み取りや小さなテーブル キャッシュなどの最新の TiDB 最適化機能を追加すると、レイテンシーが 51% 削減され、QPS が 108% 増加し、平均 TiDB CPU 使用率が 936% から 478% に低下することがわかります。
各シナリオのパフォーマンスを比較すると、次の結論を導き出すことができます。
TiDB の実行プラン キャッシュは、OLTP パフォーマンス チューニングにおいて重要な役割を果たします。v6.0.0 から導入された RC 読み取り機能と小規模テーブル キャッシュ機能も、このワークロードのさらなるパフォーマンス チューニングにおいて重要な役割を果たします。
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 内のパフォーマンスのボトルネックを特定し、それに応じてパフォーマンスを調整できます。
これらの機能を組み合わせて使用することで、実際のアプリケーションのパフォーマンスを効率的に分析および調整できます。