pingcap · yahonda · Aug 20, 2026 · Aug 20, 2026 · Aug 20, 2026 · Aug 20, 2026
diff --git a/accelerated-table-creation.md b/accelerated-table-creation.md
@@ -19,7 +19,7 @@ TiDB v7.6.0 では、テーブル作成の高速化をサポートするシス
 
 テーブル作成時のパフォーマンス最適化は、 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md)文でのみ使用可能になりました。ただし、この文には外部キー制約を含めてはなりません。
 
-## テーブル作成を高速化するには、 `tidb_enable_fast_create_table`使用してください。 {#use-tidb-enable-fast-create-table-to-accelerate-table-creation}
+## テーブル作成を高速化するには、 `tidb_enable_fast_create_table`を使用してください。 {#use-tidb-enable-fast-create-table-to-accelerate-table-creation}
 
 システム変数[`tidb_enable_fast_create_table`](/system-variables.md#tidb_enable_fast_create_table-new-in-v800)の値を指定することで、テーブル作成時のパフォーマンス最適化を有効または無効にすることができます。
 

diff --git a/ai/guides/auto-embedding.md b/ai/guides/auto-embedding.md
@@ -31,7 +31,7 @@ embed_func = EmbeddingFunction(
 
 テーブル スキーマにベクトル フィールドを作成するには、 `embed_func.VectorField()`を使用します。
 
-自動埋め込みを有効にするには、埋め込みたいフィールドに`source_field`設定します。
+自動埋め込みを有効にするには、埋め込みたいフィールドに`source_field`を設定します。
 
 ```python hl_lines="7"
 from pytidb.schema import TableModel, Field

diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md
@@ -372,7 +372,7 @@ LIMIT 10;
 <SimpleTab groupId="language">
 <div label="Python" value="python">
 
-事前フィルタリングを有効にするには、 `.filter()`方法で`prefilter=True`設定します。
+事前フィルタリングを有効にするには、 `.filter()`方法で`prefilter=True`を設定します。
 
 **例: 事前フィルタリングによるベクトル検索**
 

diff --git a/alert-rules.md b/alert-rules.md
@@ -659,7 +659,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 -   解決：
 
     1.  `warn`や`error`などの上位レベルのログの使用を検討してください。
-    2.  `[raftstore]`構成の下に`raft-base-tick-interval = "2s"`追加します。
+    2.  `[raftstore]`構成の下に`raft-base-tick-interval = "2s"`を追加します。
 
 #### `TiKV_scheduler_context_total` {#tikv_scheduler_context_total}
 

diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md
@@ -38,7 +38,7 @@ TiDBはオンラインDDLをサポートしています。つまり、データ
 
 TiDB DDLモジュールは、DDLオーナー（またはオーナー）の役割を導入します。これは、TiDBクラスタ内のすべてのDDL文を実行するプロキシとして機能します。現在の実装では、クラスタ全体から一度にオーナーとして選出できるTiDBノードは1つだけです。TiDBノードがオーナーとして選出されると、そのTiDBノードで起動されたワーカーがクラスタ内のDDLタスクを処理できるようになります。
 
-TiDBは、etcdの選出メカニズムを用いて、複数のTiDBノードからオーナーをホストするノードを選出します。デフォルトでは、各TiDBノードがオーナーとして選出される可能性があります（選出へのノードの参加を管理するには、 `run-ddl`設定します）。選出されたオーナーノードには任期があり、更新することで積極的に任期を維持します。オーナーノードがダウンした場合、etcdを介して別のノードが新しいオーナーとして選出され、クラスター内でDDLタスクの実行を継続できます。
+TiDBは、etcdの選出メカニズムを用いて、複数のTiDBノードからオーナーをホストするノードを選出します。デフォルトでは、各TiDBノードがオーナーとして選出される可能性があります（選出へのノードの参加を管理するには、 `run-ddl`を設定します）。選出されたオーナーノードには任期があり、更新することで積極的に任期を維持します。オーナーノードがダウンした場合、etcdを介して別のノードが新しいオーナーとして選出され、クラスター内でDDLタスクの実行を継続できます。
 
 DDL 所有者の簡単な説明は次のとおりです。
 

diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md
@@ -100,7 +100,7 @@ DESC TIDB_INDEX_USAGE;
 -   非効率的なインデックス:
 
     -   `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックス スキャンが実行されることを意味し、インデックスが非効率的である可能性があります。
-    -   `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。
+    -   `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`を比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。
 
 `TIDB_INDEX_USAGE`システム テーブルを使用すると、インデックスのパフォーマンスに関する詳細な情報を取得できるため、不要なインデックスを削除し、クエリ実行を最適化することが容易になります。
 

diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md
@@ -50,7 +50,7 @@ EXPLAIN FORMAT = "brief" SELECT * FROM listings WHERE price < 2000;
 +-----------------------------+---------+----------------------------------------------+---------------------------+
 ```
 
-このフィルターはパフォーマンスを向上させますが、それでも大量の行が返される可能性があります。これは、より具体的な物件を探しているユーザーには理想的ではありません。都市、寝室数、最高価格などのフィルターを追加すると、結果が大幅に絞り込まれます。例えば、サンフランシスコで`$2,000`ベッドルーム以下の物件を検索するクエリの方が有用ですが、返される行数は数十行程度になる可能性が高いでしょう。
+このフィルターはパフォーマンスを向上させますが、それでも大量の行が返される可能性があります。これは、より具体的な物件を探しているユーザーには理想的ではありません。都市、寝室数、最高価格などのフィルターを追加すると、結果が大幅に絞り込まれます。例えば、San Franciscoでベッドルームが2つあり、価格が`$2,000`未満の物件を検索するクエリの方が有用ですが、返される行数は数十行程度になる可能性が高いでしょう。
 
 このクエリを最適化するには、次のように`city` 、 `bedrooms` 、 `price`に複数列のインデックスを作成します。
 
@@ -68,24 +68,24 @@ SQLの複数列インデックスは辞書式順序で並べられます。`(cit
 
 次の表は、複数列のインデックスによって検索結果がどのように絞り込まれるかを示すサンプル データセットを示しています。
 
-| 市        | 寝室 | 価格   |
-| -------- | -- | ---- |
-| サンディエゴ   | 1  | 1000 |
-| サンディエゴ   | 1  | 1500 |
-| サンディエゴ   | 2  | 1000 |
-| サンディエゴ   | 2  | 2500 |
-| サンディエゴ   | 3  | 1000 |
-| サンディエゴ   | 3  | 2500 |
-| サンフランシスコ | 1  | 1000 |
-| サンフランシスコ | 1  | 1500 |
-| サンフランシスコ | 2  | 1000 |
-| サンフランシスコ | 2  | 1500 |
-| サンフランシスコ | 3  | 2500 |
-| サンフランシスコ | 3  | 3000 |
+| City          | Bedrooms | Price |
+| ------------- | -------- | ----- |
+| San Diego     | 1        | 1000  |
+| San Diego     | 1        | 1500  |
+| San Diego     | 2        | 1000  |
+| San Diego     | 2        | 2500  |
+| San Diego     | 3        | 1000  |
+| San Diego     | 3        | 2500  |
+| San Francisco | 1        | 1000  |
+| San Francisco | 1        | 1500  |
+| San Francisco | 2        | 1000  |
+| San Francisco | 2        | 1500  |
+| San Francisco | 3        | 2500  |
+| San Francisco | 3        | 3000  |
 
 ## 最適化されたクエリと結果 {#optimized-queries-and-results}
 
-マルチカラムインデックスを使用すると、TiDB はスキャン範囲を効率的に絞り込み、サンフランシスコでベッドルームが 2 つあり、価格が 2,000 ドル未満の物件を検索できます。
+マルチカラムインデックスを使用すると、TiDB はスキャン範囲を効率的に絞り込み、San Franciscoでベッドルームが 2 つあり、価格が 2,000 ドル未満の物件を検索できます。
 
 ```sql
 -- Query 2: Find two-bedroom listings in San Francisco under $2,000
@@ -106,10 +106,10 @@ EXPLAIN FORMAT = "brief"
 
 このクエリは、サンプル データから次のフィルター処理された結果を返します。
 
-| 市        | 寝室 | 価格   |
-| -------- | -- | ---- |
-| サンフランシスコ | 2  | 1000 |
-| サンフランシスコ | 2  | 1500 |
+| City          | Bedrooms | Price |
+| ------------- | -------- | ----- |
+| San Francisco | 2        | 1000  |
+| San Francisco | 2        | 1500  |
 
 複数列のインデックスを使用することで、TiDB は不要な行スキャンを回避し、クエリ パフォーマンスを大幅に向上させます。
 
@@ -133,7 +133,7 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが
 
 ### 例1: 重複する範囲 {#example-1-overlapping-ranges}
 
-ニューヨークで、価格が 2 つの重複する範囲のいずれかに該当する 2 ベッドルームの物件を検索するクエリを考えてみましょう。
+New Yorkで、価格が 2 つの重複する範囲のいずれかに該当する 2 ベッドルームの物件を検索するクエリを考えてみましょう。
 
 -   価格は`$1,000` ～ `$2,000`
 -   価格は`$1,500` ～ `$2,500`
@@ -160,10 +160,10 @@ EXPLAIN FORMAT = "brief"
 
 ### 例2: 重複しない範囲 {#example-2-non-overlapping-ranges}
 
-別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`異なる都市の2つの異なる範囲を指定しています。
+別のシナリオとして、San FranciscoまたはSan Diegoで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`異なる都市の2つの異なる範囲を指定しています。
 
--   サンフランシスコの物件、1ベッドルーム、価格`$1,500` ～ `$2,500`
--   サンディエゴの物件、1ベッドルーム、価格`$1,000` ～ `$1,500`
+-   San Franciscoの物件、1ベッドルーム、価格`$1,500` ～ `$2,500`
+-   San Diegoの物件、1ベッドルーム、価格`$1,000` ～ `$1,500`
 
 インデックス範囲は重複しないため、実行計画では個別のままとなり、各都市には独自のインデックス範囲が設定されます。
 

diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md
@@ -214,7 +214,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー
 -   オペレータが正常に生成されていても、スケジュール処理が遅い場合は、次のことが考えられます。
 
     -   スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。
-    -   他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`設定して一時的に無効にすることができます。
+    -   他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`を設定して一時的に無効にすることができます。
     -   スケジューリングプロセスが遅すぎます。原因を確認するには`RemovePeer` **Operator ステップの所要時間**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。
 
 -   PDは対応するバランシングスケジューラを生成できません。考えられる原因は次のとおりです。

diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md
@@ -81,7 +81,7 @@ TiDB は、SQL 構造を Key-Value 構造に自動的にマッピングします
 
 ### セカンダリインデックス {#secondary-index}
 
-TiDB は、[グローバルインデックス](/global-indexes.md)インデックスでもある完全なセカンダリインデックスをサポートしています。多くのクエリはインデックスによって最適化できます。したがって、アプリケーションではセカンダリ インデックスを有効に活用することが重要です。
+TiDB は、[グローバルインデックス](/global-indexes.md)でもある完全なセカンダリインデックスをサポートしています。多くのクエリはインデックスによって最適化できます。したがって、アプリケーションではセカンダリ インデックスを有効に活用することが重要です。
 
 MySQLで培った多くの経験は、TiDBにも応用できます。ただし、TiDBには独自の機能があることに留意してください。以下は、TiDBでセカンダリインデックスを使用する際の注意点です。
 

diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md
@@ -21,7 +21,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ
 
 -   デフォルト値`true`ままにしておくと、増分リストアを開始する前に、再生が必要なDDLが厳密にチェックされます。このモードでは、 `ADD INDEX` 、 `MODIFY COLUMN` 、 `REORG PARTITION`まだサポートされていません。増分バックアップとログバックアップを併用する場合は、増分バックアッププロセス中に、前述のDDLが存在しないことを確認してください。そうでない場合、これら3つのDDLを正しく再生できません。
 
--   リカバリプロセス全体でログ バックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`から`false`設定して増分リカバリ フェーズでのチェックをスキップできます。
+-   リカバリプロセス全体でログ バックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`を`false`に設定して増分リカバリ フェーズでのチェックをスキップできます。
 
 ## 増分データをバックアップする {#back-up-incremental-data}
 

diff --git a/check-before-deployment.md b/check-before-deployment.md
@@ -734,7 +734,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t
     passwd tidb
     ```
 
-2.  パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`追加します。
+2.  パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`を追加します。
 
     ```bash
     visudo

diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md
@@ -85,19 +85,19 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ
         tiup diag config clinic.token ${token-value}
         ```
 
-3.  Diag に`region`設定します。
+3.  Diag に`region`を設定します。
 
-    `region` 、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例:
+    `region`は、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例:
 
     > **Note:**
     >
-    > -   Diag v0.9.0 以降のバージョンでは設定`region`サポートされます。
-    > -   Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`設定してください。
+    > -   Diag v0.9.0 以降のバージョンでは`region`の設定がサポートされます。
+    > -   Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`を設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`を設定してください。
 
     <SimpleTab groupId="clinicServer">
      <div label="Clinic Server for international users" value="clinic-us">
 
-    国際ユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`US`設定します。
+    国際ユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`US`に設定します。
 
     ```bash
     tiup diag config clinic.region US
@@ -106,7 +106,7 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ
     </div>
      <div label="Clinic Server for users in the Chinese mainland" value="clinic-cn">
 
-    中国本土のユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`CN`設定します。
+    中国本土のユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`CN`に設定します。
 
     ```bash
     tiup diag config clinic.region CN
@@ -199,7 +199,7 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ
     Do you want to continue? [y/N]: (default=N)
     ```
 
-2.  データの収集を開始することを確認するには、 `Y`入力します。
+2.  データの収集を開始することを確認するには、 `Y`を入力します。
 
     データの収集には一定の時間がかかります。収集するデータの量によって時間は異なります。例えば、テスト環境では1GBのデータの収集に約10分かかります。
-Original file line number
+Diff line change
@@ Expand Up @@
         passwd tidb
         ```
-.  パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`追加します。
+.  パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`を追加します。
         ```bash
         visudo
@@ Expand Down @@