pingcap · qiancai · Aug 20, 2026 · Aug 20, 2026 · Aug 20, 2026 · Aug 20, 2026
diff --git a/latency-breakdown.md b/latency-breakdown.md
@@ -95,7 +95,7 @@ Diagram(
 )
 ```
 
-ポイント獲得中、 `tidb_session_execute_duration_seconds{type="general"}`期間は次のように計算されます。
+PointGetの実行中、 `tidb_session_execute_duration_seconds{type="general"}`期間は次のように計算されます。
 
 ```text
 tidb_session_execute_duration_seconds{type="general"} =
@@ -321,11 +321,11 @@ Diagram(
 
 実行フェーズでは、TiDBはメモリ内のデータを操作します。主なレイテンシーは必要なデータの読み取りに起因します。更新クエリと削除クエリの場合、TiDBはまずTiKVからデータを読み取り、次にメモリ内の行を更新または削除します。
 
-例外はPointGetとバッチPointGetによるロックタイム読み取り操作（ `SELECT FOR UPDATE` ）で、これは1回のリモートプロシージャコール（RPC）で読み取りとロックを実行します。
+例外はPointGetとBatch PointGetによるロック取得時の読み取り操作（ `SELECT FOR UPDATE` ）で、これは1回のリモートプロシージャコール（RPC）で読み取りとロックを実行します。
 
-### Lock Time PointGet {#lock-time-point-get}
+### ロック取得時のPointGet {#lock-time-point-get}
 
-以下は、Lock Time PointGet操作の時間コスト図です。
+以下は、ロック取得時のPointGet操作の時間コスト図です。
 
 ```railroad+diagram
 Diagram(
@@ -342,7 +342,7 @@ Diagram(
 )
 ```
 
-ロックタイムポイントの取得中、 `execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は次のように計算されます。
+ロック取得時のPointGetの実行中、 `execution(clustered PK)`期間と`execution(non-clustered PK or UK)`期間は次のように計算されます。
 
 ```text
 execution(clustered PK) =
@@ -351,11 +351,11 @@ execution(non-clustered PK or UK) =
     2 * tidb_tikvclient_txn_cmd_duration_seconds{type="lock_keys"}
 ```
 
-Lock Time PointGetはキーをロックし、その値を返します。実行後のロックフェーズと比較すると、1ラウンドトリップを節約できます。Lock Time PointGetの実行時間は[ロック期間](#lock)として扱うことができます。
+ロック取得時のPointGetはキーをロックし、その値を返します。実行後のロックフェーズと比較すると、1ラウンドトリップを節約できます。ロック取得時のPointGetの実行時間は[ロック期間](#lock)として扱うことができます。
 
-### Lock Time Batch PointGet {#lock-time-batch-point-get}
+### ロック取得時のBatch PointGet {#lock-time-batch-point-get}
 
-以下は、Lock Time Batch PointGet操作の時間コスト図です。
+以下は、ロック取得時のBatch PointGet操作の時間コスト図です。
 
 ```railroad+diagram
 Diagram(
@@ -369,7 +369,7 @@ Diagram(
 )
 ```
 
-Lock Time Batch PointGetの実行中、 `execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は次のように計算されます。
+ロック取得時のBatch PointGetの実行中、 `execution(clustered PK)`期間と`execution(non-clustered PK or UK)`期間は次のように計算されます。
 
 ```text
 execution(clustered PK) =
@@ -379,7 +379,7 @@ execution(non-clustered PK or UK) =
     tidb_tikvclient_txn_cmd_duration_seconds{type="lock_keys"}
 ```
 
-Lock Time Batch PointGetの実行は、1回のRPCで複数の値を読み取る点を除けば、 [Lock Time PointGet](#lock-time-point-get)と同様です。 `tidb_tikvclient_txn_cmd_duration_seconds{type="batch_get"}`所要時間の詳細については、 [Batch PointGet](#batch-point-get)セクションを参照してください。
+ロック取得時のBatch PointGetの実行は、1回のRPCで複数の値を読み取る点を除けば、 [ロック取得時のPointGet](#lock-time-point-get)と同様です。 `tidb_tikvclient_txn_cmd_duration_seconds{type="batch_get"}`所要時間の詳細については、 [Batch PointGet](#batch-point-get)セクションを参照してください。
 
 ### ロック {#lock}
 
@@ -724,7 +724,7 @@ async write duration(async io enabled) =
 
 非同期書き込みは次の 3 つのフェーズに分けられます。
 
--   提案する
+-   提案
 -   コミット
 -   適用：上記の式に`tikv_raftstore_apply_wait_time_duration_secs + tikv_raftstore_apply_log_duration_seconds`を代入する
 

diff --git a/optimizer-hints.md b/optimizer-hints.md
@@ -782,7 +782,7 @@ select /*+ READ_CONSISTENT_REPLICA() */ * from t;
 prepare stmt from 'select  /*+ IGNORE_PLAN_CACHE() */ * from t where t.id = ?';
 ```
 
-### SET_VAR(変数名=変数値) {#set_varvar_namevar_value}
+### SET_VAR(VAR_NAME=VAR_VALUE) {#set_varvar_namevar_value}
 
 `SET_VAR(VAR_NAME=VAR_VALUE)`ヒントを使用すると、文の実行中にシステム変数の値を一時的に変更できます。文の実行後、現在のセッションにおけるシステム変数の値は自動的に元の値に戻ります。このヒントは、オプティマイザとエグゼキュータに関連する一部のシステム変数を変更するために使用できます。このヒントを使用して変更できるシステム変数のリストについては、 [システム変数](/system-variables.md)を参照してください。
 
@@ -815,7 +815,7 @@ SELECT @@MAX_EXECUTION_TIME;
 1 row in set (0.00 sec)
 ```
 
-### ストレート結合() {#straight_join}
+### STRAIGHT_JOIN() {#straight_join}
 
 `STRAIGHT_JOIN()`ヒントは、結合プランを生成するときに、 `FROM`句のテーブル名の順序でテーブルを結合するようにオプティマイザーに通知します。
 
@@ -846,7 +846,7 @@ SELECT /*+ NTH_PLAN(3) */ count(*) from t where a > 5;
 >
 > `NTH_PLAN(N)`は主にテスト用に使用されており、それ以降のバージョンとの互換性は保証されていません。このヒントは**慎重に**使用してください。
 
-### RESOURCE_GROUP(リソースグループ名) {#resource_groupresource_group_name}
+### RESOURCE_GROUP(resource_group_name) {#resource_groupresource_group_name}
 
 `RESOURCE_GROUP(resource_group_name)`は、[リソース管理](/tidb-resource-control-ru-groups.md)でリソースを分離するために使用されます。このヒントは、指定されたリソースグループを使用して現在のステートメントを一時的に実行します。指定されたリソースグループが存在しない場合、このヒントは無視されます。
 
@@ -1087,7 +1087,7 @@ EXPLAIN SELECT /*+ leading(t1, t3), inl_join(t3) */ * FROM t1, t2, t3 WHERE t1.i
 `Can't find a proper physical plan for this query`エラーは次のシナリオで発生する可能性があります。
 
 -   クエリ自体はインデックスを順番に読み取る必要はありません。つまり、このクエリでは、ヒントを使用しない限り、オプティマイザはインデックスを順番に読み取るプランを生成しません。この場合、ヒント`ORDER_INDEX`が指定されていると、このエラーが発生します。この問題を解決するには、対応するヒント`ORDER_INDEX`を削除してください。
--   クエリは、 `NO_JOIN`関連するヒントを使用して、可能なすべての結合方法を除外します。
+-   クエリは、 `NO_JOIN`に関連するヒントを使用して、可能なすべての結合方法を除外します。
 
 ```sql
 CREATE TABLE t1 (a INT);

diff --git a/pd-control.md b/pd-control.md
@@ -216,7 +216,7 @@ tiup ctl:v<CLUSTER_VERSION> pd -u https://127.0.0.1:2379 --cacert="path/to/ca" -
     config set enable-cross-table-merge true  // Enable cross table merge.
     ```
 
--   `key-type` 、クラスターで使用されるキーエンコーディングの種類を指定します。サポートされているオプションは ["table", "raw", "txn"] で、デフォルト値は "table" です。
+-   `key-type`はクラスターで使用されるキーエンコーディングの種類を指定します。サポートされているオプションは ["table", "raw", "txn"] で、デフォルト値は "table" です。
 
     -   クラスター内に TiDB インスタンスが存在しない場合は、 `key-type` 「raw」または「txn」になり、PD は`enable-cross-table-merge`設定に関係なくテーブル間でリージョンをマージできます。
     -   クラスター内にTiDBインスタンスが存在する場合、 `key-type`は 「table」である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。`key-type`が 「raw」の場合、配置ルールは機能しません。
@@ -231,19 +231,19 @@ tiup ctl:v<CLUSTER_VERSION> pd -u https://127.0.0.1:2379 --cacert="path/to/ca" -
     config set region-score-formula-version v2
     ```
 
--   `patrol-region-interval` 、チェッカーがリージョンのヘルスステータスを検査する実行頻度を制御します。間隔が短いほど、実行頻度が高くなります。通常、調整する必要はありません。
+-   `patrol-region-interval`はチェッカーがリージョンのヘルスステータスを検査する実行頻度を制御します。間隔が短いほど、実行頻度が高くなります。通常、調整する必要はありません。
 
     ```bash
     config set patrol-region-interval 10ms // Set the execution frequency of the checker to 10ms
     ```
 
--   `patrol-region-worker-count` 、リージョンのヘルス状態を検査する際にチェッカーによって作成される同時実行数[オペレーター](/glossary.md#operator)を制御します。通常、この設定を調整する必要はありません。この設定項目を 1 より大きい値に設定すると、同時実行チェックが有効になります。現在、この機能は実験的であり、本番環境での使用は推奨されません。
+-   `patrol-region-worker-count`は、リージョンのヘルス状態を検査する際にチェッカーが同時に実行する[オペレーター](/glossary.md#operator)の数を制御します。通常、この設定を調整する必要はありません。この設定項目を 1 より大きい値に設定すると、同時実行チェックが有効になります。現在、この機能は実験的であり、本番環境での使用は推奨されません。
 
     ```bash
     config set patrol-region-worker-count 2 // Set the checker concurrency to 2
     ```
 
--   `max-store-down-time` 、PD が切断されたストアを復元できないと判断するまでの時間を制御します。指定された時間内に PD がストアからハートビートを受信しない場合、PD は他のノードにレプリカを追加します。
+-   `max-store-down-time`は、PD が切断されたストアをダウンとみなすまでの時間を制御します。指定された時間内に PD がストアからハートビートを受信しない場合、PD は他のノードにレプリカを追加します。
 
     ```bash
     config set max-store-down-time 30m  // Set the time within which PD receives no heartbeats and after which PD starts to add replicas to 30 minutes
@@ -1107,12 +1107,12 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope
     scheduler config balance-hot-region-scheduler set src-tolerance-ratio 1.1
     ```
 
--   `read-priorities` 、 `write-leader-priorities` 、 `write-peer-priorities` 、ホットリージョンスケジューリングにおいてスケジューラがどのディメンションを優先するかを制御します。設定では2つのディメンションがサポートされています。
+-   `read-priorities` 、 `write-leader-priorities` 、 `write-peer-priorities`はホットリージョンスケジューリングにおいてスケジューラがどのディメンションを優先するかを制御します。設定では2つのディメンションがサポートされています。
 
-    -   `read-priorities` 、読み取りタイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`cpu` 、 `query` 、 `byte` 、 `key`です。
-    -   `write-leader-priorities` 、書き込みリーダータイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`query` 、 `byte` 、 `key`です。
+    -   `read-priorities`は読み取りタイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`cpu` 、 `query` 、 `byte` 、 `key`です。
+    -   `write-leader-priorities`は書き込みリーダータイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`query` 、 `byte` 、 `key`です。
 
-    -   `write-peer-priorities` 、書き込みピアタイプのホットリージョンのスケジュールにおいて、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`byte`と`key`です。
+    -   `write-peer-priorities`は書き込みピアタイプのホットリージョンのスケジュールにおいて、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`byte`と`key`です。
 
     > **Note:**
     >
@@ -1133,14 +1133,14 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope
 -   `rank-formula-version`は、ホットリージョンスケジューリングで使用するスケジューラアルゴリズムのバージョンを制御します。値の選択肢は`v1`と`v2`です。デフォルト値は`v2`です。
 
     -   `v1`アルゴリズムは、TiDB v6.3.0以前のバージョンで使用されていたスケジューラ戦略です。このアルゴリズムは、主にストア間の負荷差を軽減することに重点を置いており、他のディメンションへの副作用の発生を回避します。
-    -   `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、副作用を少なくしながら、ストアとファクタ間の公平性を向上させることに主眼を置いています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。
-    -   `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。
+    -   `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、ストア間の公平性の向上を主な目的としつつ、副作用も考慮しています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第1次元の均等化をより重視しています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第2次元のバランスを考慮しています。
+    -   `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第1次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。
 
   ```bash
   scheduler config balance-hot-region-scheduler set rank-formula-version v2
   ```
 
--   `enable-for-tiflash` 、 TiFlashインスタンス間のホットリージョンスケジューリングを有効にするかどうかを制御します。通常は有効です。無効にすると、 TiFlashインスタンス間のホットリージョンスケジューリングは実行されません。
+-   `enable-for-tiflash`はTiFlashインスタンス間のホットリージョンスケジューリングを有効にするかどうかを制御します。通常は有効です。無効にすると、 TiFlashインスタンス間のホットリージョンスケジューリングは実行されません。
 
     ```bash
     scheduler config balance-hot-region-scheduler set enable-for-tiflash true