pingcap · yahonda · Jul 21, 2026
diff --git a/ai/concepts/vector-search-overview.md b/ai/concepts/vector-search-overview.md
@@ -43,7 +43,7 @@ TiDB は、ベクトル埋め込みのstorageと検索を最適化するよう
 
 生データをベクトル埋め込みに変換してTiDBに保存した後、アプリケーションはベクトル検索クエリを実行して、ユーザーのクエリに対して意味的または文脈的に最も関連性の高いデータを見つけることができます。
 
-TiDBベクトル検索は、 [距離関数](/ai/reference/vector-search-functions-and-operators.md)指定されたベクトルとデータベースに格納されているベクトル間の距離を計算するために用いられます。クエリで指定されたベクトルに最も近いベクトルは、意味的に最も類似したデータを表します。
+TiDBベクトル検索は、 [距離関数](/ai/reference/vector-search-functions-and-operators.md)が指定されたベクトルとデータベースに格納されているベクトル間の距離を計算するために用いられます。クエリで指定されたベクトルに最も近いベクトルは、意味的に最も類似したデータを表します。
 
 ![The Schematic TiDB Vector Search](/media/vector-search/embedding-search.png)
 

diff --git a/ai/reference/vector-search-functions-and-operators.md b/ai/reference/vector-search-functions-and-operators.md
@@ -130,7 +130,7 @@ SELECT VEC_L2_DISTANCE('[0, 3]', '[4, 0]');
 VEC_COSINE_DISTANCE(vector1, vector2)
 ```
 
-次の式を使用して 2 つのベクトル間の[コサイン距離](https://en.wikipedia.org/wiki/Cosine_similarity)計算します。
+次の式を使用して 2 つのベクトル間の[コサイン距離](https://en.wikipedia.org/wiki/Cosine_similarity)を計算します。
 
 $距離(p,q)=1.0 - {\frac {\sum \limits *{i=1}^{n}{p* {i}q_{i}}}{{\sqrt {\sum \limits *{i=1}^{n}{p* {i}^{2}}}}\cdot {\sqrt {\sum \limits *{i=1}^{n}{q* {i}^{2}}}}}}$
 

diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md
@@ -70,7 +70,7 @@ HNSW ベクトル インデックスを作成するときは、ベクトルの
 
 ベクトルインデックスは、固定次元のベクトル列（例えば、 `VECTOR(3)`と定義された列）に対してのみ作成できます。ベクトル距離は、同じ次元のベクトル間でのみ計算できるため、非固定次元のベクトル列（例えば、 `VECTOR`と定義された列）には作成できません。
 
-ベクトル検索インデックスの制限と制約については、 [制限](#restrictions)参照してください。
+ベクトル検索インデックスの制限と制約については、 [制限](#restrictions)を参照してください。
 
 ## ベクトルインデックスを使用する {#use-the-vector-index}
 

diff --git a/alert-rules.md b/alert-rules.md
@@ -861,7 +861,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー
 -   解決：
     -   Grafana Node Exporter ダッシュボードでホストの CPU 使用率と負荷平均を確認し、それらが高すぎないかどうかを確認します。
 
-    -   マシンにログインして`top`実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがないか確認します。
+    -   マシンにログインして`top`を実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがないか確認します。
 
 #### `NODE_cpu_used_more_than_80%` {#node-cpu-used-more-than-80}
 
@@ -876,7 +876,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー
 -   解決：
     -   Grafana Node Exporter ダッシュボードでホストの CPU 使用率と負荷平均を確認し、それらが高すぎないかどうかを確認します。
 
-    -   マシンにログインして`top`実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがあるかどうかを確認します。
+    -   マシンにログインして`top`を実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがあるかどうかを確認します。
 
 #### `NODE_tcp_estab_num_more_than_50000` {#node-tcp-estab-num-more-than-50000}
 

diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md
@@ -96,7 +96,7 @@ SQL文の実行中に、TiDBは複数のTiKVインスタンスからデータを
 # Cop_wait: Avg_time: 1ms P90_time: 2ms Max_time: 110ms Max_Addr: 10.6.131.78
 ```
 
-上記のログは、インスタンス`10.6.131.78`に送信された`cop-task`実行されるまでに`110ms`待機していることを示しています。これは、このインスタンスがビジー状態であることを示しています。その時点のCPUモニタリングを確認することで、原因を確認できます。
+上記のログは、インスタンス`10.6.131.78`に送信された`cop-task`が実行されるまでに`110ms`待機していることを示しています。これは、このインスタンスがビジー状態であることを示しています。その時点のCPUモニタリングを確認することで、原因を確認できます。
 
 #### 廃止されたMVCCバージョンと過剰なキー {#obsolete-mvcc-versions-and-excessive-keys}
 
@@ -157,7 +157,7 @@ mysql> explain analyze select count(*) from t where a=(select max(t1.a) from t t
 
 TiDBの実行プランは正しいものの、実行速度が遅い場合を考えてみましょう。このような問題を解決するには、SQL文の`EXPLAIN ANALYZE`の結果に応じてパラメータを調整するか、ヒントを使用します。
 
-実行プランが正しくない場合は、セクション[オプティマイザーの問題を分析する](#analyze-optimizer-issues)参照してください。
+実行プランが正しくない場合は、セクション[オプティマイザーの問題を分析する](#analyze-optimizer-issues)を参照してください。
 
 #### 同時実行性が低い {#low-concurrency}
 
@@ -233,7 +233,7 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a;
 1.  `select * from t` : フィルター条件はなく、テーブル全体のスキャンが実行されます。そのため、データの読み取りには`TableFullScan`演算子が使用されます。
 2.  `select a from t where a=2` : フィルター条件があり、インデックス列のみが読み取られるため、 `IndexReader`演算子を使用してデータを読み取ります。
 3.  `select * from t where a=2` : `a`のフィルター条件がありますが、 `a`インデックスでは読み取るデータを完全にカバーできないため、 `IndexLookup`演算子が使用されます。
-4.  `select b from t where c=3` : プレフィックス条件がないと、マルチカラムインデックスは使用できません。そのため、 `IndexFullScan`使用されます。
+4.  `select b from t where c=3` : プレフィックス条件がないと、マルチカラムインデックスは使用できません。そのため、 `IndexFullScan`が使用されます。
 5.  ...
 
 上記の例は、データ読み取りに使用される演算子です。その他の演算子については、 [TiDB実行プランを理解する](/explain-overview.md)参照してください。

diff --git a/auto-increment.md b/auto-increment.md
@@ -457,7 +457,7 @@ IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発
 >
 > -   v6.4.0 より前では、各 ID 割り当てに TiKV トランザクションが必要であり、パフォーマンスに影響します。
 > -   v6.4.0 では、TiDB は、ID 割り当てをメモリ内操作として実行する集中割り当てサービスを導入し、パフォーマンスを大幅に向上させました。
-> -   v8.1.0以降、TiDBはプライマリノード終了時の自動的な`forceRebase`操作を削除し、再起動を高速化します。これによりフェイルオーバー時に非連続のIDが追加される可能性がありますが、多くのテーブルで`AUTO_ID_CACHE 1`使用されている場合に書き込みブロックが発生するのを防ぎます。
+> -   v8.1.0以降、TiDBはプライマリノード終了時の自動的な`forceRebase`操作を削除し、再起動を高速化します。これによりフェイルオーバー時に非連続のIDが追加される可能性がありますが、多くのテーブルで`AUTO_ID_CACHE 1`が使用されている場合に書き込みブロックが発生するのを防ぎます。
 
 ## 制限 {#restrictions}
 

diff --git a/auto-random.md b/auto-random.md
@@ -7,7 +7,7 @@ summary: AUTO_RANDOM 属性について学習します。
 
 ## ユーザーシナリオ {#user-scenario}
 
-`AUTO_RANDOM`の値はランダムかつ一意であるため、TiDBが連続したIDを割り当てることで単一ストレージノードに書き込みホットスポットが発生するのを回避するため、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`使用されることがよくあります。現在の`AUTO_INCREMENT`列が主キーで、型が`BIGINT`場合、 `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);`ステートメントを実行して`AUTO_INCREMENT`から`AUTO_RANDOM`に切り替えることができます。
+`AUTO_RANDOM`の値はランダムかつ一意であるため、TiDBが連続したIDを割り当てることで単一ストレージノードに書き込みホットスポットが発生するのを回避するため、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`が使用されることがよくあります。現在の`AUTO_INCREMENT`列が主キーで、型が`BIGINT`の場合、 `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);`ステートメントを実行して`AUTO_INCREMENT`から`AUTO_RANDOM`に切り替えることができます。
 
 <CustomContent platform="tidb">
 
@@ -210,4 +210,4 @@ ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000;
 -   `AUTO_RANDOM`属性で指定された主キー列の列タイプを変更することはできません。
 -   同じ列に同時に`AUTO_RANDOM`と`AUTO_INCREMENT`指定することはできません。
 -   同じ列に`AUTO_RANDOM`と`DEFAULT` (列のデフォルト値) を同時に指定することはできません。
--   列に`AUTO_RANDOM`使用されている場合、自動生成される値が非常に大きくなる可能性があるため、列属性を`AUTO_INCREMENT`に戻すのは困難です。
+-   列に`AUTO_RANDOM`が使用されている場合、自動生成される値が非常に大きくなる可能性があるため、列属性を`AUTO_INCREMENT`に戻すのは困難です。
diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md
@@ -215,7 +215,7 @@ SELECT * FROM sys.schema_unused_indexes;
 
 重要だが頻度の低いクエリにインデックスが表示される場合は、まずインデックスを保持するか不可視にすることをお勧めします。
 
-[不可視インデックス](#safely-test-index-removal-using-invisible-indexes)使用すると、パフォーマンスに影響を与えずにインデックスを削除できるかどうかを安全にテストできます。
+[不可視インデックス](#safely-test-index-removal-using-invisible-indexes)を使用すると、パフォーマンスに影響を与えずにインデックスを削除できるかどうかを安全にテストできます。
 
 ### <code>schema_unused_indexes</code>ビューを手動で作成する {#manually-create-the-code-schema-unused-indexes-code-view}
 

diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md
@@ -32,7 +32,7 @@ tiup br restore full \
 --ddl-batch-size=1
 ```
 
-この機能が無効にされると、 BR は代わりに[シリアル実行実装](#implementation)使用します。
+この機能が無効にされると、 BR は代わりに[シリアル実行実装](#implementation)を使用します。
 
 ## 実装 {#implementation}
 

diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md
@@ -29,7 +29,7 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを
 
 バックアップ中、 `br` PD内のバックアップスナップショット`gc-safepoint`を定期的に更新し、データのガベージコレクションを回避します。5 `br`終了すると、 `gc-safepoint`時間内に更新されません。その結果、次のバックアップ再試行までに、データがガベージコレクションされている可能性があります。
 
-このような状況を回避するため、 `gcttl`指定されていない場合、 `br`デフォルトで`gc-safepoint`約1時間保持します。必要に応じて、 `gcttl`パラメータを設定することで保持期間を延長できます。
+このような状況を回避するため、 `gcttl`が指定されていない場合、 `br`はデフォルトで`gc-safepoint`を約1時間保持します。必要に応じて、 `gcttl`パラメータを設定することで保持期間を延長できます。
 
 次の例では、 `gcttl` 15 時間 (54000 秒) に設定して、保持期間`gc-safepoint`を延長します。
 

diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md
@@ -147,7 +147,7 @@ PITRの全プロセスは以下のとおりです。
 
 ログバックアップでは、以下の種類のファイルが生成されます。
 
--   `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`ファイル: 各 TiKV ノードがログ バックアップ データをアップロードするたびに生成され、今回アップロードされたすべてのログ バックアップ データ ファイルのメタデータが保存されます。ファイル名の各フィールドの意味については、[バックアップファイルの構造](#structure-of-backup-files)参照してください。
+-   `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`ファイル: 各 TiKV ノードがログ バックアップ データをアップロードするたびに生成され、今回アップロードされたすべてのログ バックアップ データ ファイルのメタデータが保存されます。ファイル名の各フィールドの意味については、[バックアップファイルの構造](#structure-of-backup-files)を参照してください。
 -   `{store_id}.ts`ファイル: 各 TiKV ノードがログバックアップデータをアップロードするたびに、グローバルチェックポイント ts で更新されます。 `{store_id}`は TiKV ノードのストア ID です。
 -   `{min_ts}-{uuid}.log`ファイル: バックアップ タスクの KV 変更ログ データを格納します。 `{min_ts}`は、ファイル内の KV 変更ログ データの最小 TSO タイムスタンプであり、 `{uuid}`はファイル作成時にランダムに生成されます。
 -   `v1_stream_truncate_safepoint.txt`ファイル: `br log truncate`によって削除されたストレージ内の最新のバックアップデータに対応するタイムスタンプを保存します。

diff --git a/character-set-and-collation.md b/character-set-and-collation.md
@@ -172,7 +172,7 @@ GBK 文字セットの TiDB サポートの詳細については、 [GBK](/chara
 
 ## TiDB の<code>utf8</code>と<code>utf8mb4</code> {#code-utf8-code-and-code-utf8mb4-code-in-tidb}
 
-MySQLでは、文字セット`utf8`最大3バイトに制限されています。これは基本多言語面（BMP）の文字を格納するには十分ですが、絵文字などの文字を格納するには不十分です。新規インストールの場合は、文字セット`utf8mb4`使用し、文字セット`utf8`から移行することをお勧めします。
+MySQLでは、文字セット`utf8`は最大3バイトに制限されています。これは基本多言語面（BMP）の文字を格納するには十分ですが、絵文字などの文字を格納するには不十分です。新規インストールの場合は、文字セット`utf8mb4`を使用し、文字セット`utf8`から移行することをお勧めします。
 
 MySQL と TiDB の両方で、 `utf8`と`utf8mb3`同じ文字セットのエイリアスです。
 

diff --git a/check-before-deployment.md b/check-before-deployment.md
@@ -400,7 +400,7 @@ sudo systemctl enable ntpd.service
 
     > **Note:**
     >
-    > `[always] madvise never`出力された場合、THP が有効になっています。無効にする必要があります。
+    > `[always] madvise never`が出力された場合、THP が有効になっています。無効にする必要があります。
 
 2.  次のコマンドを実行して、データ ディレクトリが配置されているディスクのI/O Scheduler を確認します。
 
@@ -415,7 +415,7 @@ sudo systemctl enable ntpd.service
 
     > **Note:**
     >
-    > `noop [deadline] cfq`出力された場合、ディスクのI/Oスケジューラは`deadline`モードになっています。これを`noop`に変更する必要があります。
+    > `noop [deadline] cfq`が出力された場合、ディスクのI/Oスケジューラは`deadline`モードになっています。これを`noop`に変更する必要があります。
 
     データ ディレクトリで NVMe デバイスを使用している場合は、次のコマンドを実行してI/Oスケジューラを確認します。
 
@@ -456,7 +456,7 @@ sudo systemctl enable ntpd.service
 
     > **Note:**
     >
-    > `The governor "powersave"`出力された場合、 cpufreq モジュールの電源ポリシーは`powersave`です。これを`performance`に変更する必要があります。仮想マシンまたはクラウドホストを使用している場合、出力は通常`Unable to determine current policy`であり、何も変更する必要はありません。
+    > `The governor "powersave"`が出力された場合、 cpufreq モジュールの電源ポリシーは`powersave`です。これを`performance`に変更する必要があります。仮想マシンまたはクラウドホストを使用している場合、出力は通常`Unable to determine current policy`であり、何も変更する必要はありません。
 
 5.  オペレーティング システムの最適なパラメータを構成します。