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..c9daab645c0c3 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}
 
@@ -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)
 
@@ -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}
 
@@ -58,12 +58,12 @@ useServerPrepStmts=false
 
 ![performance-overview-1-for-query-interface](/media/performance/j-1.png)
 
-- SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。
-- SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。
-- SQL 実行時間の概要: `Get` 、および`tso wait` `Cop`ほとんどの時間がかかります。
-- タイプ別 CPS: `Query`コマンドのみが使用されます。
-- プランキャッシュ OPS を使用したクエリ: データなしは、実行計画 キャッシュがヒットしていないことを示します。
-- クエリ期間では、レイテンシー`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: データなしは、実行プランキャッシュがヒットしていないことを示します。
+- クエリ実行時間では、`execute`と`compile`のレイテンシーの割合が最も高くなります。
 - 平均QPS = 56.8k
 
 クラスタのリソース消費量を確認すると、TiDB CPUの平均使用率は925%、TiKV CPUの平均使用率は201%、TiKV IOの平均スループットは18.7 MB/sでした。TiDBのリソース消費量が大幅に高くなっています。
@@ -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
@@ -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)
 
@@ -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}
 
@@ -106,13 +106,13 @@ useServerPrepStmts=false&useConfigs=maxPerformance
 
 ![performance-overview-1-for-maxPerformance](/media/performance/j-2.png)
 
-- SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。
-- SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。
-- SQL 実行時間の概要: `Get` `Prewrite`および`tso wait` `Cop`ほとんどの時間がかかります。
-- データベース時間では、レイテンシー`execute`と`compile`割合が最も高くなります。
-- タイプ別 CPS: `Query`コマンドのみが使用されます。
+- 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`コマンドのみが使用されます。
 - 平均QPS = 24.2k (56.3kから24.2k)
-- 実行計画 キャッシュにヒットしません。
+- 実行プランキャッシュにヒットしません。
 
 シナリオ 1 からシナリオ 2 にかけて、TiDB の平均 CPU 使用率は 925% から 874% に低下し、TiKV の平均 CPU 使用率は 201% から約 250% に増加します。
 
@@ -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消費量を削減し、レイテンシーを短縮します。
 
@@ -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}
 
@@ -162,14 +162,14 @@ 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` `Prewrite`および`tso wait` `Cop`ほとんどの時間がかかります。
-- タイプ別 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)
-- 実行計画 キャッシュにヒットしません。
+- 実行プランキャッシュにヒットしません。
 
 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実行では既存の実行計画を再利用でき、実行計画の繰り返しコンパイルを回避できます。
 
@@ -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秒
 
@@ -214,15 +214,15 @@ 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 実行時間の概要: `tso wait` 、および`Cop` `Get`ほとんどの時間がかかります。
-- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリの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)
 
@@ -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}
 
@@ -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秒
 
@@ -273,15 +273,15 @@ 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)
 
-- SQL タイプ別のデータベース時間: `Select`文 タイプが最も多くの時間を費やし、 `general`ステートメント タイプは消えます。
-- SQL フェーズ別のデータベース時間: フェーズ`execute`がほとんどの時間を費やします。
-- SQL 実行時間の概要: `tso wait` 、および`Cop` `Get`ほとんどの時間がかかります。
-- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリの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%に増加しました。
@@ -302,9 +302,9 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加
 ### 分析の結論 {#analysis-conclusion}
 
 - シナリオ 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マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。
+- 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を要求する必要があるためです。
 
 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` 、および`Prewrite` `Cop`ほとんどの時間がかかります。
-- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリの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に減少します。
@@ -357,15 +357,15 @@ 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読み取りリクエストの待機時間とリソース消費を削減できます。
+現在のデータベース時間とレイテンシーの両方のボトルネックは`execute`フェーズにあり、このフェーズでは`Get`と`Cop`の読み取りリクエストが最も高い割合を占めています。このワークロードのテーブルのほとんどは読み取り専用か、ほとんど変更されないため、TiDB v6.0.0以降でサポートされている小さなテーブルのキャッシュ機能を使用して、これらの小さなテーブルのデータをキャッシュすることで、KV読み取りリクエストの待機時間とリソース消費を削減できます。
 
 ## シナリオ7: 小さなテーブルキャッシュを使用する {#scenario-7-use-the-small-table-cache}
 
 ### アプリケーション構成 {#application-configuration}
 
-シナリオ6と比較して、アプリケーション構成は同じです。唯一の違いは、シナリオ7では、ビジネス用に読み取り専用テーブルをキャッシュするために、 `alter table t1 cache;`ようなSQL文を使用する点です。
+シナリオ6と比較して、アプリケーション構成は同じです。唯一の違いは、シナリオ7では、ビジネス用に読み取り専用テーブルをキャッシュするために、 `alter table t1 cache;`のようなSQL文を使用する点です。
 
 ### パフォーマンス分析 {#performance-analysis}
 
@@ -377,15 +377,15 @@ 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)
 
-- SQL タイプ別のデータベース時間: `Select`文 タイプがほとんどの時間を費やします。
-- SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。
-- SQL 実行時間の概要: `Prewrite` 、および`Get` `Commit`ほとんどの時間がかかります。
-- 実行プランキャッシュがヒットしました。プランキャッシュを使用するクエリの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% に低下します。
@@ -403,7 +403,7 @@ QPSは34.9kから40.9kに増加し、KVリクエストタイプはフェーズ`e
 
 ### 分析の結論 {#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リクエストタイプはフェーズ`e
 
 | メトリクス | シナリオ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接続パラメータを設定することで、アプリケーションは最高のパフォーマンスを実現できます。