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が割り当てられています。
• クライアントサーバー構成：36CPU。

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

アプリケーション構成

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

useServerPrepStmts=false

パフォーマンス分析

TiDBダッシュボード

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

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

• ExecuteStmt cpu = 38％cpu time = 23.84s
• コンパイルCPU=27％CPU時間= 17.17s
• CPUの最適化=26％CPU時間= 16.41s

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

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

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

クラスタのリソース消費量を確認します。TiDBCPUの平均使用率は925％、TiKV CPUの平均使用率は201％、TiKVIOの平均スループットは18.7MB/秒です。 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 time = 35.84s
• コンパイルCPU=31％CPU時間= 25.61s
• CPUの最適化=30％CPU時間= 24.74s

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

データベース時間の概要と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は大幅に減少しています。平均クエリ期間と平均parse 、およびcompile期間が大幅に増加しexecuteた。これは、シナリオ1のselect @@session.transaction_read_onlyなどのSQLステートメントが何度も実行され、処理時間が速いため、平均パフォーマンスデータが低下するためです。シナリオ2がそのようなステートメントをブロックした後、ビジネス関連のSQLステートメントのみが残るため、平均期間が長くなります。

アプリケーションがクエリインターフェイスを使用する場合、TiDBは実行プランキャッシュを使用できません。その結果、TiDBは実行プランをコンパイルするために大量のリソースを消費します。この場合、Prepared Statementインターフェイスを使用することをお勧めします。このインターフェイスは、TiDBの実行プランキャッシュを使用して、実行プランのコンパイルによって発生するTiDB CPU消費を減らし、遅延を減らします。

シナリオ3.実行プランのキャッシュが有効になっていないプリペアドステートメントインターフェイスを使用する

アプリケーション構成

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

useServerPrepStmts=true&useConfigs=maxPerformance"

パフォーマンス分析

TiDBダッシュボード

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

• ExecutePreparedStmt cpu = 31％cpu time = 23.10s
• prepareStmtExec cpu = 30％cpu time = 22.92s
• CompileExecutePreparedStmt cpu = 24％cpu時間= 17.83s
• CPUの最適化=23％CPU時間= 17.29s

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

プリペアドステートメントインターフェイスを使用した後のデータベース時間の概要と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： StmtExecute種類のコマンド（ StmtPrepare ）が使用され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のアプリケーションは、プリペアドステートメントインターフェイスを有効にしますが、それでもキャッシュにヒットしません。さらに、シナリオ2には1つのCPS By Typeコマンドタイプ（ Query ）しかありませんが、シナリオ3にはさらに3 StmtClose StmtPrepareがありStmtExecute 。シナリオ2と比較すると、シナリオ3にはさらに2つのネットワークラウンドトリップ遅延があります。

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

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

シナリオ4.プリペアドステートメントインターフェイスを使用して、実行プランのキャッシュを有効にします

アプリケーション構成

アプリケーションの構成はシナリオ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.75s

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

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

• SQLタイプ別のデータベース時間： Selectステートメントタイプが最も時間がかかります。
• SQLフェーズごとのデータベース時間： executeフェーズはほとんどの時間を要します。
• SQL実行時間の概要： tso wait 、およびGetがほとんどの時間を要しCop 。
• 実行プランのキャッシュがヒットしました。 Plan Cache OPSを使用したクエリの値は、ほぼStmtExecute秒あたり1になります。
• タイプ別の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 time = 8.4s

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

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

• SQLタイプ別のデータベース時間： Selectステートメントタイプはほとんどの時間を要し、 generalステートメントタイプは消えます。
• SQLフェーズごとのデータベース時間： executeフェーズはほとんどの時間を要します。
• SQL実行時間の概要： tso wait 、およびGetがほとんどの時間を要しCop 。
• 実行プランのキャッシュがヒットしました。 Plan Cache OPSを使用したクエリの値は、ほぼStmtExecute秒あたり1になります。
• タイプ別の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）
• avg pdtso待機時間=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回は196usで、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のステートメントは、最新のPDTSOを使用します。

シナリオ6： tidb_rc_read_check_ts変数を有効にして、TSO要求を減らします

アプリケーション構成

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

パフォーマンス分析

ダッシュボード

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

• ExecutePreparedStmt cpu = 22％cpu time = 8.4s

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

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

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

tso cmd秒あたり1は、28.3kから2.7kに低下します。

平均的なTiDBCPUは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）
• avg pdtso待機時間=171μs（196μsから171μs）

分析の結論

RC読み取りをset global tidb_rc_read_check_ts=on;だけ有効にすると、RC読み取りはtso cmdの時間を大幅に短縮し、 tso waitと平均クエリ期間を短縮し、QPSを向上させます。

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

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

アプリケーション構成

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

パフォーマンス分析

TiDBダッシュボード

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

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

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 、およびCommitがほとんどの時間を要しGet 。
• 実行プランのキャッシュがヒットしました。 Plan Cache OPSを使用したクエリの値は、ほぼStmtExecute秒あたり1になります。
• タイプ別のCPS： StmtExecuteのコマンドのみが使用されます。
• 平均QPS=40.9k（34.9kから40.9k）

平均TiDBCPU使用率は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）

分析の結論

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

実際のビジネスでは読み取り専用テーブルのデータが大きすぎてTiDBがすべてをキャッシュできない可能性があるため、これは楽観的な結果です。もう1つの制限は、小さなテーブルのキャッシュ機能は書き込み操作をサポートしますが、すべてのTiDBノードのキャッシュが最初に無効になるように、書き込み操作にはデフォルトで3秒の待機が必要です。これは、厳密な遅延要件を持つアプリケーションでは実行できない場合があります。

概要

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

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

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

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

• TiDBの実行プランキャッシュは、OLTPパフォーマンスの調整において重要な役割を果たします。 v6.0.0から導入されたRC読み取りおよびスモールテーブルキャッシュ機能も、このワークロードのさらなるパフォーマンス調整において重要な役割を果たします。

• TiDBは、MySQLプロトコルのさまざまなコマンドと互換性があります。プリペアドステートメントインターフェイスを使用し、次の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内のパフォーマンスのボトルネックを特定し、それに応じてパフォーマンスを調整できます。

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