From f4d94be576700e08a7c82bdcadfe82de920f72d2 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 11:40:48 +0900 Subject: [PATCH 01/14] i18n(ja): fix phase-name word order to match corpus convention --- dm/dm-hardware-and-software-requirements.md | 2 +- performance-tuning-practices.md | 20 ++++++++++---------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/dm/dm-hardware-and-software-requirements.md b/dm/dm-hardware-and-software-requirements.md index 8923c12521762..162897eabc075 100644 --- a/dm/dm-hardware-and-software-requirements.md +++ b/dm/dm-hardware-and-software-requirements.md @@ -32,7 +32,7 @@ DMは、64ビット汎用ハードウェアサーバープラットフォーム > - テスト環境では、機能検証に使用する DM-master と DM-worker を同じサーバー上にデプロイできます。 > - パフォーマンス テスト結果の精度を損なわないようにするために、低パフォーマンスのストレージおよびネットワーク ハードウェア構成を使用することは**お勧めしません**。 > - 機能の検証のみが必要な場合は、DM-masterを1台のマシンにデプロイできます。デプロイするDM-workerの数は、上流のMySQLインスタンスの数以上である必要があります。高可用性を確保するには、より多くのDM-workerをデプロイすることをお勧めします。 -> - DM-workerはフェーズ`dump`とフェーズ`load`で全データを保存します。そのため、DM-workerのディスク容量は、移行するデータの総量よりも大きくする必要があります。移行タスクでリレーログが有効になっている場合、DM-workerは上流のbinlogデータを保存するために追加のディスク容量を必要とします。 +> - DM-workerは`dump`フェーズと`load`フェーズで全データを保存します。そのため、DM-workerのディスク容量は、移行するデータの総量よりも大きくする必要があります。移行タスクでリレーログが有効になっている場合、DM-workerは上流のbinlogデータを保存するために追加のディスク容量を必要とします。 ### 本番環境 {#production-environment} diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 53daab9725a0b..effa2fb49271a 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -59,7 +59,7 @@ useServerPrepStmts=false ![performance-overview-1-for-query-interface](/media/performance/j-1.png) - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。 +- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL 実行時間の概要: `Get` 、および`tso wait` `Cop`ほとんどの時間がかかります。 - タイプ別 CPS: `Query`コマンドのみが使用されます。 - プランキャッシュ OPS を使用したクエリ: データなしは、実行計画 キャッシュがヒットしていないことを示します。 @@ -107,7 +107,7 @@ useServerPrepStmts=false&useConfigs=maxPerformance ![performance-overview-1-for-maxPerformance](/media/performance/j-2.png) - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。 +- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL 実行時間の概要: `Get` `Prewrite`および`tso wait` `Cop`ほとんどの時間がかかります。 - データベース時間では、レイテンシー`execute`と`compile`割合が最も高くなります。 - タイプ別 CPS: `Query`コマンドのみが使用されます。 @@ -165,7 +165,7 @@ Prepared Statement インターフェイスを使用した後、データベー QPSは24.4kから19.7kに低下しています。データベース時間の概要を見ると、アプリケーションが3種類のPreparedコマンドを使用しており、 `general`ステートメントタイプ（ `StmtPrepare`や`StmtClose`などのコマンドの実行時間を含む）がSQLタイプ別のデータベース時間で2番目に多いことがわかります。これは、Prepared Statementインターフェースを使用しても、実行プランキャッシュにヒットしていないことを示しています。これは、 `StmtClose`コマンド実行時に、TiDBが内部処理でSQL文の実行プランキャッシュをクリアするためです。 - SQL タイプ別のデータベース時間: `Select`文 タイプが最も時間がかかり、次に`general`ステートメントが続きます。 -- SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。 +- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL 実行時間の概要: `Get` `Prewrite`および`tso wait` `Cop`ほとんどの時間がかかります。 - タイプ別 CPS: 3種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 - 平均QPS = 19.7k (24.4kから19.7k) @@ -214,12 +214,12 @@ PreparseStmt CPU = 25% CPU 時間 = 12.75秒 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} -パフォーマンス概要ダッシュボードで最も顕著な変化は、フェーズ`compile`の平均時間です。シナリオ3の8.95秒/秒から1.18秒/秒に短縮されています。実行プランキャッシュを使用するクエリの数は、 `StmtExecute`の値とほぼ等しくなります。QPSの増加に伴い、1秒あたり`Select`文のデータベース消費時間は減少し、1秒あたり`general`ステートメントのデータベース消費時間は増加しています。 +パフォーマンス概要ダッシュボードで最も顕著な変化は、`compile`フェーズの平均時間です。シナリオ3の8.95秒/秒から1.18秒/秒に短縮されています。実行プランキャッシュを使用するクエリの数は、 `StmtExecute`の値とほぼ等しくなります。QPSの増加に伴い、1秒あたり`Select`文のデータベース消費時間は減少し、1秒あたり`general`ステートメントのデータベース消費時間は増加しています。 ![performance-overview-1-for-3-commands](/media/performance/j-4.png) - SQL タイプ別のデータベース時間: `Select`文 タイプが最も時間がかかります。 -- SQL フェーズ別のデータベース時間: フェーズ`execute`がほとんどの時間を費やします。 +- SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 - SQL 実行時間の概要: `tso wait` 、および`Cop` `Get`ほとんどの時間がかかります。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - CPSタイプ別: 3種類のコマンド（シナリオ3と同じ） @@ -278,7 +278,7 @@ useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCache ![performance-overview-for-1-command](/media/performance/j-5.png) - SQL タイプ別のデータベース時間: `Select`文 タイプが最も多くの時間を費やし、 `general`ステートメント タイプは消えます。 -- SQL フェーズ別のデータベース時間: フェーズ`execute`がほとんどの時間を費やします。 +- SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 - SQL 実行時間の概要: `tso wait` 、および`Cop` `Get`ほとんどの時間がかかります。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 @@ -331,7 +331,7 @@ RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 ` ![performance-overview-1-for-rc-read](/media/performance/j-6.png) - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: フェーズ`execute`がほとんどの時間を費やします。 +- SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 - SQL 実行時間の概要: `Get` 、および`Prewrite` `Cop`ほとんどの時間がかかります。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 @@ -359,7 +359,7 @@ RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 ` 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読み取りリクエストの待機時間とリソース消費を削減できます。 +現在のデータベース時間とレイテンシーの両方のボトルネックは`execute`フェーズにあり、このフェーズでは`Get`と`Cop`の読み取りリクエストが最も高い割合を占めています。このワークロードのテーブルのほとんどは読み取り専用か、ほとんど変更されないため、TiDB v6.0.0以降でサポートされている小さなテーブルのキャッシュ機能を使用して、これらの小さなテーブルのデータをキャッシュすることで、KV読み取りリクエストの待機時間とリソース消費を削減できます。 ## シナリオ7: 小さなテーブルキャッシュを使用する {#scenario-7-use-the-small-table-cache} @@ -377,12 +377,12 @@ TiDB CPU のフレーム チャートには大きな変化はありません。 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} -QPSは34.9kから40.9kに増加し、KVリクエストタイプはフェーズ`execute`からフェーズ`Prewrite`とフェーズ`Commit`への変更で最も時間がかかります。1秒あたり`Get`のデータベース処理時間は5.33秒から1.75秒に短縮され、1秒あたり`Cop`のデータベース処理時間は3.87秒から1.09秒に短縮されます。 +QPSは34.9kから40.9kに増加し、KVリクエストタイプは`execute`フェーズから`Prewrite`フェーズと`Commit`フェーズへの変更で最も時間がかかります。1秒あたり`Get`のデータベース処理時間は5.33秒から1.75秒に短縮され、1秒あたり`Cop`のデータベース処理時間は3.87秒から1.09秒に短縮されます。 ![performance-overview-1-for-table-cache](/media/performance/j-7.png) - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。 +- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL 実行時間の概要: `Prewrite` 、および`Get` `Commit`ほとんどの時間がかかります。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 From df54c166d4340f1305f1377308e50d534d7acb38 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:02:05 +0900 Subject: [PATCH 02/14] i18n(ja): fix word-order scramble and dropped particle in SQL execute time bullets --- performance-tuning-practices.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index effa2fb49271a..4df7f458bc977 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -60,10 +60,10 @@ useServerPrepStmts=false - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 - SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Get` 、および`tso wait` `Cop`ほとんどの時間がかかります。 +- SQL 実行時間の概要: `Get`、`Cop`、および`tso wait`がほとんどの時間を費やします。 - タイプ別 CPS: `Query`コマンドのみが使用されます。 - プランキャッシュ OPS を使用したクエリ: データなしは、実行計画 キャッシュがヒットしていないことを示します。 -- クエリ期間では、レイテンシー`execute`と`compile`割合が最も高くなります。 +- クエリ期間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 - 平均QPS = 56.8k クラスタのリソース消費量を確認すると、TiDB CPUの平均使用率は925%、TiKV CPUの平均使用率は201%、TiKV IOの平均スループットは18.7 MB/sでした。TiDBのリソース消費量が大幅に高くなっています。 @@ -108,8 +108,8 @@ useServerPrepStmts=false&useConfigs=maxPerformance - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 - SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Get` `Prewrite`および`tso wait` `Cop`ほとんどの時間がかかります。 -- データベース時間では、レイテンシー`execute`と`compile`割合が最も高くなります。 +- SQL 実行時間の概要: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 +- データベース時間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 - タイプ別 CPS: `Query`コマンドのみが使用されます。 - 平均QPS = 24.2k (56.3kから24.2k) - 実行計画 キャッシュにヒットしません。 @@ -166,7 +166,7 @@ QPSは24.4kから19.7kに低下しています。データベース時間の概 - SQL タイプ別のデータベース時間: `Select`文 タイプが最も時間がかかり、次に`general`ステートメントが続きます。 - SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Get` `Prewrite`および`tso wait` `Cop`ほとんどの時間がかかります。 +- SQL 実行時間の概要: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 - タイプ別 CPS: 3種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 - 平均QPS = 19.7k (24.4kから19.7k) - 実行計画 キャッシュにヒットしません。 @@ -220,7 +220,7 @@ PreparseStmt CPU = 25% CPU 時間 = 12.75秒 - SQL タイプ別のデータベース時間: `Select`文 タイプが最も時間がかかります。 - SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 -- SQL 実行時間の概要: `tso wait` 、および`Cop` `Get`ほとんどの時間がかかります。 +- SQL 実行時間の概要: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - CPSタイプ別: 3種類のコマンド（シナリオ3と同じ） - シナリオ 3 と比較すると、QPS が増加したため、 `general`ステートメントで消費される時間が長くなります。 @@ -279,7 +279,7 @@ useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCache - SQL タイプ別のデータベース時間: `Select`文 タイプが最も多くの時間を費やし、 `general`ステートメント タイプは消えます。 - SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 -- SQL 実行時間の概要: `tso wait` 、および`Cop` `Get`ほとんどの時間がかかります。 +- SQL 実行時間の概要: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 - 平均QPS = 30.9k (22.1kから30.9k) @@ -332,7 +332,7 @@ RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 ` - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 - SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 -- SQL 実行時間の概要: `Get` 、および`Prewrite` `Cop`ほとんどの時間がかかります。 +- SQL 実行時間の概要: `Get`、`Cop`、および`Prewrite`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 - 平均QPS = 34.9k (30.9kから34.9k) @@ -383,7 +383,7 @@ QPSは34.9kから40.9kに増加し、KVリクエストタイプは`execute`フ - SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 - SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Prewrite` 、および`Get` `Commit`ほとんどの時間がかかります。 +- SQL 実行時間の概要: `Prewrite`、`Commit`、および`Get`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 - タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 - 平均QPS = 40.9k (34.9kから40.9k) From 8ebfc36b7a95497978d2672df969c4888dca10db Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:03:24 +0900 Subject: [PATCH 03/14] i18n(ja): fix causality scramble in KV request type phase-change sentence --- performance-tuning-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 4df7f458bc977..b90c085bbe890 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -377,7 +377,7 @@ TiDB CPU のフレーム チャートには大きな変化はありません。 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} -QPSは34.9kから40.9kに増加し、KVリクエストタイプは`execute`フェーズから`Prewrite`フェーズと`Commit`フェーズへの変更で最も時間がかかります。1秒あたり`Get`のデータベース処理時間は5.33秒から1.75秒に短縮され、1秒あたり`Cop`のデータベース処理時間は3.87秒から1.09秒に短縮されます。 +QPSは34.9kから40.9kに増加し、最も時間がかかるKVリクエストタイプが`execute`フェーズから`Prewrite`フェーズと`Commit`フェーズに変わりました。1秒あたり`Get`のデータベース処理時間は5.33秒から1.75秒に短縮され、1秒あたり`Cop`のデータベース処理時間は3.87秒から1.09秒に短縮されます。 ![performance-overview-1-for-table-cache](/media/performance/j-7.png) From b6a141289e5502ff232728251c06093ac6abb8e6 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:04:22 +0900 Subject: [PATCH 04/14] i18n(ja): disambiguate client-server-configuration wording --- performance-tuning-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index b90c085bbe890..15a7bd0b77826 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -24,7 +24,7 @@ TiDB は、TiDB Dashboardの[Top SQL](/dashboard/top-sql.md)と[継続的なプ - トランザクションで使用されるテーブル: 合計 60 テーブル。12 テーブルは更新操作に関連し、残りの 48 テーブルは読み取り専用です。 - アプリケーションで使用される分離レベル: `read committed` 。 - TiDB クラスター構成: 3つの TiDB ノードと 3つの TiKV ノード、各ノードに 16 個の CPU が割り当てられます。 -- クライアントサーバー構成: 36 個の CPU。 +- クライアント用サーバーの構成: 36 個の CPU。 ## シナリオ1. クエリインターフェースを使用する {#scenario-1-use-the-query-interface} From 221c2b87ab407675000c8db7efb611e717ca4976 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:06:26 +0900 Subject: [PATCH 05/14] i18n(ja): fix dropped ga particle before verbs in TiDB Dashboard SQL type descriptions --- performance-tuning-practices.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 15a7bd0b77826..ed7c1836d8392 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -40,7 +40,7 @@ useServerPrepStmts=false #### TiDB Dashboard {#tidb-dashboard} -下記のTiDB Dashboardの「Top SQL」ページを見ると、非ビジネスSQLタイプ`SELECT @@session.tx_isolation`最も多くのリソースを消費していることがわかります。TiDBはこれらのタイプのSQL文を迅速に処理しますが、実行回数が最も多く、全体的なCPU消費時間も最も高くなります。 +下記のTiDB Dashboardの「Top SQL」ページを見ると、非ビジネスSQLタイプ`SELECT @@session.tx_isolation`が最も多くのリソースを消費していることがわかります。TiDBはこれらのタイプのSQL文を迅速に処理しますが、実行回数が最も多く、全体的なCPU消費時間も最も高くなります。 ![dashboard-for-query-interface](/media/performance/case1.png) @@ -88,7 +88,7 @@ useServerPrepStmts=false&useConfigs=maxPerformance #### TiDB Dashboard {#tidb-dashboard} -下記の TiDB DashboardのTop SQLページを見ると、最も多くのリソースを消費していた`SELECT @@session.tx_isolation`消えていることがわかります。 +下記の TiDB DashboardのTop SQLページを見ると、最も多くのリソースを消費していた`SELECT @@session.tx_isolation`が消えていることがわかります。 ![dashboard-for-maxPerformance](/media/performance/case2.png) @@ -303,7 +303,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 - QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 -- SQLフェーズ別データベース時間では、 `execute`最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 +- SQLフェーズ別データベース時間では、 `execute`が最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`が最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 - 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。`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 が使用されます。 From 24a499933f0ae8032481b396cb4ae4c52f85287c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:07:19 +0900 Subject: [PATCH 06/14] i18n(ja): fix particle drops and time/count confusion in RC-read analysis paragraph --- performance-tuning-practices.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index ed7c1836d8392..7796f4927164f 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -302,9 +302,9 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 ### 分析の結論 {#analysis-conclusion} - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 -- QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 +- QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`を非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 - SQLフェーズ別データベース時間では、 `execute`が最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`が最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 -- 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。`tso wait`実行時間の平均は196マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。 +- 1秒あたりの`tso wait`実行時間の合計は5.46秒です。`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 が使用されます。 From 733d963c896eeb65e57f64bbc6024bf63721d76e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:08:27 +0900 Subject: [PATCH 07/14] i18n(ja): restore literal CPU flame-graph function names Compile and Optimize --- performance-tuning-practices.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 7796f4927164f..03f8f9b548fc0 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -49,8 +49,8 @@ useServerPrepStmts=false ![flame-graph-for-query-interface](/media/performance/7.1.png) - ExecuteStmt CPU = 38% CPU時間 = 23.84秒 -- コンパイルCPU = 27% CPU時間 = 17.17秒 -- CPUを最適化 = 26%、CPU時間 = 16.41秒 +- Compile CPU = 27% CPU時間 = 17.17秒 +- Optimize CPU = 26%、CPU時間 = 16.41秒 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} @@ -97,8 +97,8 @@ useServerPrepStmts=false&useConfigs=maxPerformance ![flame-graph-for-maxPerformance](/media/performance/20220507-145257.jpg) - ExecuteStmt CPU = 43% CPU時間 =35.84秒 -- コンパイルCPU = 31% CPU時間 = 25.61秒 -- CPUを最適化 = 30% CPU時間 = 24.74秒 +- Compile CPU = 31% CPU時間 = 25.61秒 +- Optimize CPU = 30% CPU時間 = 24.74秒 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} @@ -154,7 +154,7 @@ useServerPrepStmts=true&useConfigs=maxPerformance" - ExecutePreparedStmt CPU = 31% CPU時間 = 23.10秒 - preparedStmtExec CPU = 30% CPU時間 = 22.92秒 - CompileExecutePreparedStmt CPU = 24% CPU時間 = 17.83秒 -- CPUを最適化 = 23% CPU時間 = 17.29秒 +- Optimize CPU = 23% CPU時間 = 17.29秒 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} From 1b612a1e4dc26efab38c75c399683750f7011a8e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:10:29 +0900 Subject: [PATCH 08/14] i18n(ja): fix missing punctuation and dropped average repetition in parse/compile/execute duration sentence --- performance-tuning-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 03f8f9b548fc0..e6a5b0729d713 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -129,7 +129,7 @@ useServerPrepStmts=false&useConfigs=maxPerformance ### 分析の結論 {#analysis-conclusion} -シナリオ1と比較して、シナリオ2のQPSは大幅に減少しました。平均クエリ実行時間と、 `parse` `compile` `execute`実行時間が大幅に増加しました。これは、シナリオ1の`select @@session.transaction_read_only`のような、実行回数が多く処理時間が短いSQL文が平均パフォーマンスデータを低下させたためです。シナリオ2ではこれらのSQL文がブロックされ、業務関連のSQL文のみが残るため、平均実行時間が増加します。 +シナリオ1と比較して、シナリオ2のQPSは大幅に減少しました。平均クエリ実行時間と、平均`parse`、 `compile`、 `execute`実行時間が大幅に増加しました。これは、シナリオ1の`select @@session.transaction_read_only`のような、実行回数が多く処理時間が短いSQL文が平均パフォーマンスデータを低下させたためです。シナリオ2ではこれらのSQL文がブロックされ、業務関連のSQL文のみが残るため、平均実行時間が増加します。 アプリケーションがクエリインターフェースを使用する場合、TiDBは実行プランキャッシュを使用できないため、実行計画のコンパイルに多くのリソースを消費します。このような場合は、TiDBの実行プランキャッシュを使用するPrepared Statementインターフェースの使用をお勧めします。Prepared Statementインターフェースは、実行計画のコンパイルによるTiDBのCPU消費量を削減し、レイテンシーを短縮します。 From 7e1b259402e0ba3182caf52bf32dfdf17d1c8330 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:11:33 +0900 Subject: [PATCH 09/14] i18n(ja): fix command-name word order to match corpus convention --- performance-tuning-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index e6a5b0729d713..ca417ebb8459d 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -265,7 +265,7 @@ useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCache #### TiDB Dashboard {#tidb-dashboard} -次の TiDB のフレーム チャートから、コマンド`Prepare`の高い CPU 消費がなくなったことがわかります。 +次の TiDB のフレーム チャートから、`Prepare`コマンドの高い CPU 消費がなくなったことがわかります。 - ExecutePreparedStmt CPU = 22% CPU時間 = 8.4秒 From 09ccd8f91ce15a51e30d383edd52b3ea33f78992 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:17:52 +0900 Subject: [PATCH 10/14] i18n(ja): restore literal English Performance Overview dashboard panel names --- performance-tuning-practices.md | 70 ++++++++++++++++----------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index ca417ebb8459d..50aabd836d3ce 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -58,11 +58,11 @@ useServerPrepStmts=false ![performance-overview-1-for-query-interface](/media/performance/j-1.png) -- SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Get`、`Cop`、および`tso wait`がほとんどの時間を費やします。 -- タイプ別 CPS: `Query`コマンドのみが使用されます。 -- プランキャッシュ OPS を使用したクエリ: データなしは、実行計画 キャッシュがヒットしていないことを示します。 +- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- SQL Execute Time Overview: `Get`、`Cop`、および`tso wait`がほとんどの時間を費やします。 +- CPS By Type: `Query`コマンドのみが使用されます。 +- Queries Using Plan Cache OPS: データなしは、実行計画 キャッシュがヒットしていないことを示します。 - クエリ期間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 - 平均QPS = 56.8k @@ -106,11 +106,11 @@ useServerPrepStmts=false&useConfigs=maxPerformance ![performance-overview-1-for-maxPerformance](/media/performance/j-2.png) -- SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 +- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- SQL Execute Time Overview: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 - データベース時間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 -- タイプ別 CPS: `Query`コマンドのみが使用されます。 +- CPS By Type: `Query`コマンドのみが使用されます。 - 平均QPS = 24.2k (56.3kから24.2k) - 実行計画 キャッシュにヒットしません。 @@ -162,12 +162,12 @@ Prepared Statement インターフェイスを使用した後、データベー ![performance-overview-1-for-PrepStmts](/media/performance/j-3.png) -QPSは24.4kから19.7kに低下しています。データベース時間の概要を見ると、アプリケーションが3種類のPreparedコマンドを使用しており、 `general`ステートメントタイプ（ `StmtPrepare`や`StmtClose`などのコマンドの実行時間を含む）がSQLタイプ別のデータベース時間で2番目に多いことがわかります。これは、Prepared Statementインターフェースを使用しても、実行プランキャッシュにヒットしていないことを示しています。これは、 `StmtClose`コマンド実行時に、TiDBが内部処理でSQL文の実行プランキャッシュをクリアするためです。 +QPSは24.4kから19.7kに低下しています。データベース時間の概要を見ると、アプリケーションが3種類のPreparedコマンドを使用しており、 `general`ステートメントタイプ（ `StmtPrepare`や`StmtClose`などのコマンドの実行時間を含む）がDatabase Time by SQL Typeで2番目に多いことがわかります。これは、Prepared Statementインターフェースを使用しても、実行プランキャッシュにヒットしていないことを示しています。これは、 `StmtClose`コマンド実行時に、TiDBが内部処理でSQL文の実行プランキャッシュをクリアするためです。 -- SQL タイプ別のデータベース時間: `Select`文 タイプが最も時間がかかり、次に`general`ステートメントが続きます。 -- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 -- タイプ別 CPS: 3種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 +- Database Time by SQL Type: `Select`文 タイプが最も時間がかかり、次に`general`ステートメントが続きます。 +- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- SQL Execute Time Overview: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 +- CPS By Type: 3種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 - 平均QPS = 19.7k (24.4kから19.7k) - 実行計画 キャッシュにヒットしません。 @@ -218,11 +218,11 @@ PreparseStmt CPU = 25% CPU 時間 = 12.75秒 ![performance-overview-1-for-3-commands](/media/performance/j-4.png) -- SQL タイプ別のデータベース時間: `Select`文 タイプが最も時間がかかります。 -- SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 -- SQL 実行時間の概要: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 -- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 -- CPSタイプ別: 3種類のコマンド（シナリオ3と同じ） +- Database Time by SQL Type: `Select`文 タイプが最も時間がかかります。 +- Database Time by SQL Phase: `execute`フェーズがほとんどの時間を費やします。 +- SQL Execute Time Overview: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 +- 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 +- CPS By Type: 3種類のコマンド（シナリオ3と同じ） - シナリオ 3 と比較すると、QPS が増加したため、 `general`ステートメントで消費される時間が長くなります。 - 平均QPS = 22.1k (19.7kから22.1k) @@ -277,11 +277,11 @@ useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCache ![performance-overview-for-1-command](/media/performance/j-5.png) -- SQL タイプ別のデータベース時間: `Select`文 タイプが最も多くの時間を費やし、 `general`ステートメント タイプは消えます。 -- SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 -- SQL 実行時間の概要: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 -- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 -- タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 +- Database Time by SQL Type: `Select`文 タイプが最も多くの時間を費やし、 `general`ステートメント タイプは消えます。 +- Database Time by SQL Phase: `execute`フェーズがほとんどの時間を費やします。 +- SQL Execute Time Overview: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 +- 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 +- CPS By Type: `StmtExecute`コマンドのみが使用されます。 - 平均QPS = 30.9k (22.1kから30.9k) TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加すると、TiKVの平均CPU使用率は313%に増加しました。 @@ -303,7 +303,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 - QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`を非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 -- SQLフェーズ別データベース時間では、 `execute`が最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`が最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 +- Database Time by SQL Phaseでは、 `execute`が最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL Execute Time Overviewでは、 `tso wait`が最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 - 1秒あたりの`tso wait`実行時間の合計は5.46秒です。`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 が使用されます。 @@ -330,11 +330,11 @@ RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 ` ![performance-overview-1-for-rc-read](/media/performance/j-6.png) -- SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: `execute`フェーズがほとんどの時間を費やします。 -- SQL 実行時間の概要: `Get`、`Cop`、および`Prewrite`がほとんどの時間を費やします。 -- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 -- タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 +- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time by SQL Phase: `execute`フェーズがほとんどの時間を費やします。 +- SQL Execute Time Overview: `Get`、`Cop`、および`Prewrite`がほとんどの時間を費やします。 +- 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 +- CPS By Type: `StmtExecute`コマンドのみが使用されます。 - 平均QPS = 34.9k (30.9kから34.9k) 1秒あたり`tso cmd`は28.3kから2.7kに減少します。 @@ -381,11 +381,11 @@ QPSは34.9kから40.9kに増加し、最も時間がかかるKVリクエスト ![performance-overview-1-for-table-cache](/media/performance/j-7.png) -- SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。 -- SQL フェーズ別のデータベース時間: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 -- SQL 実行時間の概要: `Prewrite`、`Commit`、および`Get`がほとんどの時間を費やします。 -- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリのOPSの値は、1秒あたり約`StmtExecute`です。 -- タイプ別 CPS: `StmtExecute`コマンドのみが使用されます。 +- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- SQL Execute Time Overview: `Prewrite`、`Commit`、および`Get`がほとんどの時間を費やします。 +- 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 +- CPS By Type: `StmtExecute`コマンドのみが使用されます。 - 平均QPS = 40.9k (34.9kから40.9k) 平均 TiDB CPU 使用率は 603% から 478% に低下し、平均 TiKV CPU 使用率は 346% から 256% に低下します。 From ebceb0b0907aad36bd9ac0c800f7711069300322 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:21:23 +0900 Subject: [PATCH 11/14] i18n(ja): unify query-duration and execution-plan-cache terminology --- performance-tuning-practices.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 50aabd836d3ce..bd3a9882d9162 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -62,8 +62,8 @@ useServerPrepStmts=false - Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL Execute Time Overview: `Get`、`Cop`、および`tso wait`がほとんどの時間を費やします。 - CPS By Type: `Query`コマンドのみが使用されます。 -- Queries Using Plan Cache OPS: データなしは、実行計画 キャッシュがヒットしていないことを示します。 -- クエリ期間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 +- Queries Using Plan Cache OPS: データなしは、実行プランキャッシュがヒットしていないことを示します。 +- クエリ実行時間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 - 平均QPS = 56.8k クラスタのリソース消費量を確認すると、TiDB CPUの平均使用率は925%、TiKV CPUの平均使用率は201%、TiKV IOの平均スループットは18.7 MB/sでした。TiDBのリソース消費量が大幅に高くなっています。 @@ -112,7 +112,7 @@ useServerPrepStmts=false&useConfigs=maxPerformance - データベース時間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 - CPS By Type: `Query`コマンドのみが使用されます。 - 平均QPS = 24.2k (56.3kから24.2k) -- 実行計画 キャッシュにヒットしません。 +- 実行プランキャッシュにヒットしません。 シナリオ 1 からシナリオ 2 にかけて、TiDB の平均 CPU 使用率は 925% から 874% に低下し、TiKV の平均 CPU 使用率は 201% から約 250% に増加します。 @@ -169,7 +169,7 @@ QPSは24.4kから19.7kに低下しています。データベース時間の概 - SQL Execute Time Overview: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 - CPS By Type: 3種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 - 平均QPS = 19.7k (24.4kから19.7k) -- 実行計画 キャッシュにヒットしません。 +- 実行プランキャッシュにヒットしません。 TiDB の平均 CPU 使用率は 874% から 936% に増加します。 @@ -189,7 +189,7 @@ TiDB の平均 CPU 使用率は 874% から 936% に増加します。 シナリオ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`と`StmtClose`は QPS にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4分の 1 以上を占めています。 -- 平均クエリ時間が大幅に短縮された理由の分析：シナリオ3で新たに追加されたコマンドタイプ`StmtPrepare`と`StmtClose`については、TiDB内部処理においてクエリ時間が個別に計算されます。TiDBはこれらの2種類のコマンドを非常に高速に実行するため、平均クエリ時間が大幅に短縮されます。 +- 平均クエリ実行時間が大幅に短縮された理由の分析：シナリオ3で新たに追加されたコマンドタイプ`StmtPrepare`と`StmtClose`については、TiDB内部処理においてクエリ実行時間が個別に計算されます。TiDBはこれらの2種類のコマンドを非常に高速に実行するため、平均クエリ実行時間が大幅に短縮されます。 シナリオ3ではPrepared Statementインターフェースを使用していますが、多くのアプリケーションフレームワークはメモリリークを防ぐためにメソッド`StmtExecute`の後にメソッド`StmtClose`を呼び出すため、実行計画のキャッシュは依然としてアクセスされません。v6.0.0以降では、グローバル変数`tidb_ignore_prepared_cache_close_stmt=on;`を設定できます。その後、アプリケーションがメソッド`StmtClose`を呼び出しても、TiDBはキャッシュされた実行計画をクリアしません。そのため、次のSQL実行では既存の実行計画を再利用でき、実行計画の繰り返しコンパイルを回避できます。 @@ -302,7 +302,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 ### 分析の結論 {#analysis-conclusion} - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 -- QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`を非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 +- QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ実行時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`を非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ実行時間が増加するためです。 - Database Time by SQL Phaseでは、 `execute`が最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL Execute Time Overviewでは、 `tso wait`が最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 - 1秒あたりの`tso wait`実行時間の合計は5.46秒です。`tso wait`の実行時間の平均は196マイクロ秒、1秒あたりの`tso cmd`実行回数は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。 @@ -357,7 +357,7 @@ RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 ` ### 分析の結論 {#analysis-conclusion} -RC Read を`set global tidb_rc_read_check_ts=on;`で有効にした後、RC Read によって`tso cmd`の時間が大幅に短縮され、 `tso wait`と平均クエリ期間が短縮され、QPS が向上しました。 +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読み取りリクエストの待機時間とリソース消費を削減できます。 @@ -403,7 +403,7 @@ QPSは34.9kから40.9kに増加し、最も時間がかかるKVリクエスト ### 分析の結論 {#analysis-conclusion} -すべての読み取り専用テーブルをキャッシュした後、 `Execute Duration`は大幅に低下します。これは、すべての読み取り専用テーブルが TiDB にキャッシュされ、それらのテーブルに対して TiKV でデータをクエリする必要がないため、クエリ期間が短縮され、QPS が増加するためです。 +すべての読み取り専用テーブルをキャッシュした後、 `Execute Duration`は大幅に低下します。これは、すべての読み取り専用テーブルが TiDB にキャッシュされ、それらのテーブルに対して TiKV でデータをクエリする必要がないため、クエリ実行時間が短縮され、QPS が増加するためです。 これは楽観的結果です。実際の業務では、読み取り専用テーブルのデータはTiDBがすべてをキャッシュするには大きすぎる可能性があります。また、小さなテーブルのキャッシュ機能は書き込み操作をサポートしますが、書き込み操作にはデフォルトで3秒間の待機時間が必要であり、これはすべてのTiDBノードのキャッシュが無効化されることを保証するためです。これは、レイテンシー要件が厳しいアプリケーションには適さない可能性があります。 @@ -413,17 +413,17 @@ QPSは34.9kから40.9kに増加し、最も時間がかかるKVリクエスト | メトリクス | シナリオ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% | -41% | +| クエリ実行時間 | 479μs | 1120μs | 528μs | 426μs | 690μs | 533μs | 313μs | -38% | -41% | | QPS | 56.3k | 24.2k | 19.7k | 22.1k | 30.9k | 34.9k | 40.9k | +28% | +108% | これらのシナリオでは、シナリオ 2 はアプリケーションがクエリ インターフェイスを使用する一般的なシナリオであり、シナリオ 5 はアプリケーションがプリペアドステートメント インターフェイスを使用する理想的なシナリオです。 -- シナリオ 5 とシナリオ 2 を比較すると、 Javaアプリケーション開発のベストプラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすることで、各 SQL文で実行計画 キャッシュをヒットするために必要なコマンドとデータベース操作が 1つだけになり、クエリのレイテンシーが 38% 短縮され、QPS が 28% 増加し、TiDB の平均 CPU 使用率が 936% から 577% に低下していることがわかります。 +- シナリオ 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の実行プランキャッシュは、OLTPパフォーマンスチューニングにおいて重要な役割を果たします。バージョン6.0.0から導入されたRC Read機能とスモールテーブルキャッシュ機能も、このワークロードのさらなるパフォーマンスチューニングにおいて重要な役割を果たします。 - TiDBはMySQLプロトコルの様々なコマンドと互換性があります。Prepared Statementインターフェースを使用し、以下のJDBC接続パラメータを設定することで、アプリケーションは最高のパフォーマンスを実現できます。 From 7d592dbf982508a75a86765b180edc12cf3425b9 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:37:40 +0900 Subject: [PATCH 12/14] i18n(ja): fix eliminate-vs-reduce mistranslations and dropped no particle --- performance-tuning-practices.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index bd3a9882d9162..df3c873c1b159 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -78,7 +78,7 @@ useServerPrepStmts=false ### アプリケーション構成 {#application-configuration} -シナリオ1では、アプリケーションはJDBC接続文字列に新しいパラメータ`useConfigs=maxPerformance`を追加します。このパラメータを使用することで、JDBCからデータベースに送信されるSQL文（例： `select @@session.transaction_read_only` ）を削減できます。完全な設定は次のとおりです。 +シナリオ1では、アプリケーションはJDBC接続文字列に新しいパラメータ`useConfigs=maxPerformance`を追加します。このパラメータを使用することで、JDBCからデータベースに送信されるSQL文（例： `select @@session.transaction_read_only` ）を排除できます。完全な設定は次のとおりです。 ``` useServerPrepStmts=false&useConfigs=maxPerformance @@ -206,7 +206,7 @@ TiDB の平均 CPU 使用率は 874% から 936% に増加します。 #### TiDB Dashboard {#tidb-dashboard} -TiDB CPU 使用率のフレーム チャートから、 `CompileExecutePreparedStmt`と`Optimize` CPU 消費量が大幅に増加していないことがわかります。CPU の 25% は`Prepare`コマンドによって消費されており、これには`PlanBuilder`や`parseSQL`などの Prepare の解析関連の関数が含まれています。 +TiDB CPU 使用率のフレーム チャートから、 `CompileExecutePreparedStmt`と`Optimize`のCPU消費量がごくわずかであることがわかります。CPU の 25% は`Prepare`コマンドによって消費されており、これには`PlanBuilder`や`parseSQL`などの Prepare の解析関連の関数が含まれています。 PreparseStmt CPU = 25% CPU 時間 = 12.75秒 @@ -243,7 +243,7 @@ PreparseStmt CPU = 25% CPU 時間 = 12.75秒 シナリオ3と比較すると、シナリオ4でも3種類のコマンドが使用されます。違いは、シナリオ4では実行プランキャッシュが使用されるため、コンパイル時間が大幅に短縮され、クエリの実行時間も短縮され、QPSが向上することです。 -`StmtPrepare`と`StmtClose`コマンドはデータベース処理時間を大量に消費し、アプリケーションがSQL文を実行するたびにアプリケーションとTiDB間のやり取りの回数を増加させます。次のシナリオでは、JDBC設定を通じてこれらの2つのコマンドの呼び出しを削減することで、パフォーマンスをさらにチューニングします。 +`StmtPrepare`と`StmtClose`コマンドはデータベース処理時間を大量に消費し、アプリケーションがSQL文を実行するたびにアプリケーションとTiDB間のやり取りの回数を増加させます。次のシナリオでは、JDBC設定を通じてこれらの2つのコマンドの呼び出しを排除することで、パフォーマンスをさらにチューニングします。 ## シナリオ5. クライアント側で準備されたオブジェクトをキャッシュする {#scenario-5-cache-prepared-objects-on-the-client-side} @@ -365,7 +365,7 @@ RC Read を`set global tidb_rc_read_check_ts=on;`で有効にした後、RC Read ### アプリケーション構成 {#application-configuration} -シナリオ6と比較して、アプリケーション構成は同じです。唯一の違いは、シナリオ7では、ビジネス用に読み取り専用テーブルをキャッシュするために、 `alter table t1 cache;`ようなSQL文を使用する点です。 +シナリオ6と比較して、アプリケーション構成は同じです。唯一の違いは、シナリオ7では、ビジネス用に読み取り専用テーブルをキャッシュするために、 `alter table t1 cache;`のようなSQL文を使用する点です。 ### パフォーマンス分析 {#performance-analysis} From cd69d0287f9821d4d84f5842995a87ca35db866c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 14:58:51 +0900 Subject: [PATCH 13/14] i18n(ja): fix KV request types incorrectly labeled as phases --- performance-tuning-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index df3c873c1b159..80e2a4635d3bf 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -377,7 +377,7 @@ TiDB CPU のフレーム チャートには大きな変化はありません。 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} -QPSは34.9kから40.9kに増加し、最も時間がかかるKVリクエストタイプが`execute`フェーズから`Prewrite`フェーズと`Commit`フェーズに変わりました。1秒あたり`Get`のデータベース処理時間は5.33秒から1.75秒に短縮され、1秒あたり`Cop`のデータベース処理時間は3.87秒から1.09秒に短縮されます。 +QPSは34.9kから40.9kに増加し、`execute`フェーズで最も時間がかかるKVリクエストタイプが`Prewrite`と`Commit`に変わりました。1秒あたり`Get`のデータベース処理時間は5.33秒から1.75秒に短縮され、1秒あたり`Cop`のデータベース処理時間は3.87秒から1.09秒に短縮されます。 ![performance-overview-1-for-table-cache](/media/performance/j-7.png) From 7e69265f92fbce9ee7deec835378a1ebf6fe197d Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 15:47:02 +0900 Subject: [PATCH 14/14] i18n(ja): correct Database Time By SQL Type/Phase panel name casing per dashboard JSON --- performance-tuning-practices.md | 34 ++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 80e2a4635d3bf..c9daab645c0c3 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -58,8 +58,8 @@ useServerPrepStmts=false ![performance-overview-1-for-query-interface](/media/performance/j-1.png) -- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 -- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- Database Time By SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time By SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL Execute Time Overview: `Get`、`Cop`、および`tso wait`がほとんどの時間を費やします。 - CPS By Type: `Query`コマンドのみが使用されます。 - Queries Using Plan Cache OPS: データなしは、実行プランキャッシュがヒットしていないことを示します。 @@ -106,8 +106,8 @@ useServerPrepStmts=false&useConfigs=maxPerformance ![performance-overview-1-for-maxPerformance](/media/performance/j-2.png) -- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 -- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- Database Time By SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time By SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL Execute Time Overview: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 - データベース時間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。 - CPS By Type: `Query`コマンドのみが使用されます。 @@ -162,10 +162,10 @@ Prepared Statement インターフェイスを使用した後、データベー ![performance-overview-1-for-PrepStmts](/media/performance/j-3.png) -QPSは24.4kから19.7kに低下しています。データベース時間の概要を見ると、アプリケーションが3種類のPreparedコマンドを使用しており、 `general`ステートメントタイプ（ `StmtPrepare`や`StmtClose`などのコマンドの実行時間を含む）がDatabase Time by SQL Typeで2番目に多いことがわかります。これは、Prepared Statementインターフェースを使用しても、実行プランキャッシュにヒットしていないことを示しています。これは、 `StmtClose`コマンド実行時に、TiDBが内部処理でSQL文の実行プランキャッシュをクリアするためです。 +QPSは24.4kから19.7kに低下しています。データベース時間の概要を見ると、アプリケーションが3種類のPreparedコマンドを使用しており、 `general`ステートメントタイプ（ `StmtPrepare`や`StmtClose`などのコマンドの実行時間を含む）がDatabase Time By SQL Typeで2番目に多いことがわかります。これは、Prepared Statementインターフェースを使用しても、実行プランキャッシュにヒットしていないことを示しています。これは、 `StmtClose`コマンド実行時に、TiDBが内部処理でSQL文の実行プランキャッシュをクリアするためです。 -- Database Time by SQL Type: `Select`文 タイプが最も時間がかかり、次に`general`ステートメントが続きます。 -- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- Database Time By SQL Type: `Select`文 タイプが最も時間がかかり、次に`general`ステートメントが続きます。 +- Database Time By SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL Execute Time Overview: `Get`、`Cop`、`Prewrite`、および`tso wait`がほとんどの時間を費やします。 - CPS By Type: 3種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 - 平均QPS = 19.7k (24.4kから19.7k) @@ -218,8 +218,8 @@ PreparseStmt CPU = 25% CPU 時間 = 12.75秒 ![performance-overview-1-for-3-commands](/media/performance/j-4.png) -- Database Time by SQL Type: `Select`文 タイプが最も時間がかかります。 -- Database Time by SQL Phase: `execute`フェーズがほとんどの時間を費やします。 +- Database Time By SQL Type: `Select`文 タイプが最も時間がかかります。 +- Database Time By SQL Phase: `execute`フェーズがほとんどの時間を費やします。 - SQL Execute Time Overview: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 - CPS By Type: 3種類のコマンド（シナリオ3と同じ） @@ -273,12 +273,12 @@ useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCache #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} -パフォーマンス概要ダッシュボードで最も注目すべき変更点は、 **CPS By Type**ペインの 3つの Stmt コマンド タイプが 1つに減り、 **Database Time by SQL Type**ペインの`general`ステートメント タイプが消え、 **QPS**ペインの QPS が 30.9k に増加したことです。 +パフォーマンス概要ダッシュボードで最も注目すべき変更点は、 **CPS By Type**ペインの 3つの Stmt コマンド タイプが 1つに減り、 **Database Time By SQL Type**ペインの`general`ステートメント タイプが消え、 **QPS**ペインの QPS が 30.9k に増加したことです。 ![performance-overview-for-1-command](/media/performance/j-5.png) -- Database Time by SQL Type: `Select`文 タイプが最も多くの時間を費やし、 `general`ステートメント タイプは消えます。 -- Database Time by SQL Phase: `execute`フェーズがほとんどの時間を費やします。 +- Database Time By SQL Type: `Select`文 タイプが最も多くの時間を費やし、 `general`ステートメント タイプは消えます。 +- Database Time By SQL Phase: `execute`フェーズがほとんどの時間を費やします。 - SQL Execute Time Overview: `tso wait`、`Get`、および`Cop`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 - CPS By Type: `StmtExecute`コマンドのみが使用されます。 @@ -303,7 +303,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 - QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ実行時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`を非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ実行時間が増加するためです。 -- Database Time by SQL Phaseでは、 `execute`が最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL Execute Time Overviewでは、 `tso wait`が最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 +- Database Time By SQL Phaseでは、 `execute`が最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL Execute Time Overviewでは、 `tso wait`が最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 - 1秒あたりの`tso wait`実行時間の合計は5.46秒です。`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 が使用されます。 @@ -330,8 +330,8 @@ RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 ` ![performance-overview-1-for-rc-read](/media/performance/j-6.png) -- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 -- Database Time by SQL Phase: `execute`フェーズがほとんどの時間を費やします。 +- Database Time By SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time By SQL Phase: `execute`フェーズがほとんどの時間を費やします。 - SQL Execute Time Overview: `Get`、`Cop`、および`Prewrite`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 - CPS By Type: `StmtExecute`コマンドのみが使用されます。 @@ -381,8 +381,8 @@ QPSは34.9kから40.9kに増加し、`execute`フェーズで最も時間がか ![performance-overview-1-for-table-cache](/media/performance/j-7.png) -- Database Time by SQL Type: `Select`文 タイプがほとんどの時間を費やします。 -- Database Time by SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 +- Database Time By SQL Type: `Select`文 タイプがほとんどの時間を費やします。 +- Database Time By SQL Phase: `execute`フェーズと`compile`フェーズにほとんどの時間がかかります。 - SQL Execute Time Overview: `Prewrite`、`Commit`、および`Get`がほとんどの時間を費やします。 - 実行プランキャッシュがヒットしました。Queries Using Plan Cache OPSの値は、1秒あたり約`StmtExecute`です。 - CPS By Type: `StmtExecute`コマンドのみが使用されます。