pingcap · qiancai · Jul 15, 2026 · Jul 15, 2026 · Jul 15, 2026 · Jul 15, 2026
diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md
@@ -68,7 +68,7 @@ CREATE TABLE documents (
 
 この例では、
 
--   `text_vec`列目は`VECTOR(3)`として定義されているため、この列に格納されるベクトルは 3 次元である必要があります。
+-   `text_vec`列は`VECTOR(3)`として定義されているため、この列に格納されるベクトルは 3 次元である必要があります。
 -   ベクトル検索のパフォーマンスを最適化するために、 `VEC_COSINE_DISTANCE`関数を使用してベクトル インデックスが作成されます。
 
 TiDB はベクトル インデックスに対して 2 つの距離関数をサポートしています。

diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md
@@ -134,7 +134,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES;
 
     参考までに、768次元の500MiBベクトルデータセットのインデックス作成には最大20分かかる場合があります。インデクサーは複数のテーブルに対して並列実行できます。現在、インデクサーの優先度や速度の調整はサポートされていません。
 
--   デルタレイヤーの行数は`ROWS_DELTA_NOT_INDEXED`列目で確認できます。TiFlashのストレージレイヤーのデータは、デルタレイヤーとステーブルレイヤーの2つのレイヤーに保存されます。デルタレイヤーには最近挿入または更新された行が保存され、書き込みワークロードに応じて定期的にステーブルレイヤーにマージされます。このマージプロセスはコンパクションと呼ばれます。
+-   デルタレイヤーの行数は`ROWS_DELTA_NOT_INDEXED`列で確認できます。TiFlashのストレージレイヤーのデータは、デルタレイヤーとステーブルレイヤーの2つのレイヤーに保存されます。デルタレイヤーには最近挿入または更新された行が保存され、書き込みワークロードに応じて定期的にステーブルレイヤーにマージされます。このマージプロセスはコンパクションと呼ばれます。
 
     Deltaレイヤーは常にインデックス化されません。最適なパフォーマンスを実現するには、DeltaレイヤーをStableレイヤーに強制的にマージし、すべてのデータがインデックス化されるようにすることができます。
 

diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md
@@ -244,4 +244,4 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a;
 
 1.  [インデックス問題の解決方法](/wrong-index-solution.md)
 2.  [結合順序が間違っています](/join-reorder.md)
-3.  [式は押し下げられない](/blocklist-control-plan.md)
+3.  [式はプッシュダウンできない](/blocklist-control-plan.md)
diff --git a/as-of-timestamp.md b/as-of-timestamp.md
@@ -15,17 +15,17 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標
 
 ## 構文 {#syntax}
 
-`AS OF TIMESTAMP`節は次の 3 つの方法で使用できます。
+`AS OF TIMESTAMP`句は次の 3 つの方法で使用できます。
 
 -   [`SELECT ... FROM ... AS OF TIMESTAMP`](/sql-statements/sql-statement-select.md)
 -   [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md)
 -   [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md)
 
-正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`節に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。3 関数を使用して、現在時刻を`NOW(3)`秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。
+正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。3 関数を使用して、現在時刻を`NOW(3)`秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。
 
 時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`使用する必要があります。5 と`t2` `t1`範囲の両端であり、datetime 値または時間関数を使用して指定できます。
 
-`AS OF TIMESTAMP`節の例をいくつか示します。
+`AS OF TIMESTAMP`句の例をいくつか示します。
 
 -   `AS OF TIMESTAMP '2016-10-08 16:45:26'` : 2016 年 10 月 8 日 16:45:26 に保存された最新のデータを読み取るように TiDB に指示します。
 -   `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` : TiDB に 10 秒前に保存された最新のデータを読み取るように指示します。
@@ -42,7 +42,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標
 
 ## 使用例 {#usage-examples}
 
-このセクションでは、いくつかの例を用いて、 `AS OF TIMESTAMP`節の様々な使用方法を説明します。まず、リカバリ用のデータの準備方法を紹介し、次に`SELECT` 、 `START TRANSACTION READ ONLY AS OF TIMESTAMP` 、 `SET TRANSACTION READ ONLY AS OF TIMESTAMP`でそれぞれ`AS OF TIMESTAMP`使用する方法を示します。
+このセクションでは、いくつかの例を用いて、 `AS OF TIMESTAMP`句の様々な使用方法を説明します。まず、リカバリ用のデータの準備方法を紹介し、次に`SELECT` 、 `START TRANSACTION READ ONLY AS OF TIMESTAMP` 、 `SET TRANSACTION READ ONLY AS OF TIMESTAMP`でそれぞれ`AS OF TIMESTAMP`使用する方法を示します。
 
 ### データサンプルを準備する {#prepare-data-sample}
 

diff --git a/auto-increment.md b/auto-increment.md
@@ -465,7 +465,7 @@ IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発
 
 -   TiDB v6.6.0 以前のバージョンの場合、定義された列は主キーまたはインデックス プレフィックスのいずれかである必要があります。
 -   `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。
--   `DEFAULT`列目の値と同じ列には指定できません。
+-   `DEFAULT`列の値と同じ列には指定できません。
 -   `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`使用することも含まれます。
 -   `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`使用して`AUTO_INCREMENT`番目の属性を削除することはできません。
 -   `ALTER TABLE` 、 `AUTO_INCREMENT`値を小さい値に設定するには`FORCE`オプションが必要です。

diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md
@@ -177,11 +177,11 @@ TiDBがインデックスを追加する際、データのバックフィルフ
 
 -   `ADMIN PAUSE DDL JOBS job_id [, job_id]` : 実行中のDDLジョブを一時停止します。コマンド実行後、バックグラウンドジョブが一時停止されている間、DDLジョブを実行するSQL文は実行中として表示されます。詳細は[`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)を参照してください。
 
-    一時停止できるのは、進行中またはキュー内にあるDDLタスクのみです。それ以外の場合は、 `RESULT`列目にエラー`Job 3 can't be paused now`が表示されます。
+    一時停止できるのは、進行中またはキュー内にあるDDLタスクのみです。それ以外の場合は、 `RESULT`列にエラー`Job 3 can't be paused now`が表示されます。
 
 -   `ADMIN RESUME DDL JOBS job_id [, job_id]` : 一時停止中のDDLタスクを再開します。コマンド実行後、DDLタスクを実行するSQL文が実行中として表示され、バックグラウンドタスクが再開されます。詳細は[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)を参照してください。
 
-    一時停止中のDDLタスクのみを再開できます。それ以外の場合は、 `RESULT`列目にエラー`Job 3 can't be resumed`が表示されます。
+    一時停止中のDDLタスクのみを再開できます。それ以外の場合は、 `RESULT`列にエラー`Job 3 can't be resumed`が表示されます。
 
 ## DDL関連テーブル {#ddl-related-tables}
 

diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md
@@ -192,11 +192,11 @@ ORDER BY
 
 **問題1:**
 
-テーブルに主キーがない場合、または主キーが`Int`型ではなく、ランダムに分布する主キーIDを生成したくない場合、TiDBは暗黙的に`_tidb_rowid`列目を行IDとして提供します。一般的に、 `SHARD_ROW_ID_BITS`列目のパラメータを使用しない場合、 `_tidb_rowid`列目の値も単調に増加するため、ホットスポットが発生する可能性があります。詳細は[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を参照してください。
+テーブルに主キーがない場合、または主キーが`Int`型ではなく、ランダムに分布する主キーIDを生成したくない場合、TiDBは暗黙的に`_tidb_rowid`列を行IDとして提供します。一般的に、 `SHARD_ROW_ID_BITS`列のパラメータを使用しない場合、 `_tidb_rowid`列の値も単調に増加するため、ホットスポットが発生する可能性があります。詳細は[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を参照してください。
 
 このような状況でホットスポット問題を回避するには、テーブル作成時に`SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`使用します。 `PRE_SPLIT_REGIONS`の詳細については、 [分割前のリージョン](/sql-statements/sql-statement-split-region.md#pre_split_regions)を参照してください。
 
-`SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列目に生成された行 ID をランダムに散布するために使用されます。4 `PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。
+`SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列に生成された行 ID をランダムに散布するために使用されます。4 `PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。
 
 > **注記：**
 >

diff --git a/best-practices/readonly-nodes.md b/best-practices/readonly-nodes.md
@@ -1,6 +1,6 @@
 ---
 title: Best Practices for Read-Only Storage Nodes
-summary: このドキュメントでは、オンラインサービスから高許容遅延負荷を分離するための読み取り専用ストレージノードの設定方法を紹介します。手順としては、TiKVノードを読み取り専用としてマークし、配置ルールを使用して読み取り専用ノードに学習者としてデータを保存し、Follower Readを使用して読み取り専用ノードからデータを読み取ることが含まれます。
+summary: このドキュメントでは、オンラインサービスから高許容遅延負荷を分離するための読み取り専用ストレージノードの設定方法を紹介します。手順としては、TiKVノードを読み取り専用としてマークし、配置ルールを使用して読み取り専用ノードにラーナーとしてデータを保存し、Follower Readを使用して読み取り専用ノードからデータを読み取ることが含まれます。
 aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/']
 ---
 
@@ -22,7 +22,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/']
         labels:
           $mode: readonly
 
-### 2. 配置ルールを使用して、学習者として読み取り専用ノードにデータを保存する {#2-use-placement-rules-to-store-data-on-read-only-nodes-as-learners}
+### 2. 配置ルールを使用して、ラーナーとして読み取り専用ノードにデータを保存する {#2-use-placement-rules-to-store-data-on-read-only-nodes-as-learners}
 
 1.  `pd-ctl config placement-rules`コマンドを実行して、デフォルトの配置ルールをエクスポートします。
 
@@ -52,7 +52,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/']
     ]
     ```
 
-2.  すべてのデータを学習者として読み取り専用ノードに保存します。以下の例はデフォルトの設定に基づいています。
+2.  すべてのデータをラーナーとして読み取り専用ノードに保存します。以下の例はデフォルトの設定に基づいています。
 
     ```json
     [
@@ -101,7 +101,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/']
 > **注記：**
 >
 > -   大規模なデータセットを持つクラスターで上記の操作を実行すると、クラスター全体のデータが読み取り専用ノードに完全に複製されるまでに時間がかかる場合があります。この間、読み取り専用ノードはサービスを提供できない可能性があります。
-> -   バックアップの特別な実装のため、各ラベルの学習者数は 1 を超えることはできません。そうでない場合、バックアップ中に重複データが生成されます。
+> -   バックアップの特別な実装のため、各ラベルのラーナー数は 1 を超えることはできません。そうでない場合、バックアップ中に重複データが生成されます。
 
 ### 3. Follower Readを使用して読み取り専用ノードからデータを読み取る {#3-use-follower-read-to-read-data-from-read-only-nodes}
 

diff --git a/character-set-and-collation.md b/character-set-and-collation.md
@@ -564,7 +564,7 @@ ERROR 1062 (23000): Duplicate entry 'a ' for key 't.PRIMARY' -- TiDB modifies th
 
 式に異なる照合順序を持つ複数の節が含まれる場合、計算で使用される照合順序を推測する必要があります。そのルールは以下のとおりです。
 
--   明示的な`COLLATE`節の強制可能性値は`0`です。
+-   明示的な`COLLATE`句の強制可能性値は`0`です。
 -   2 つの文字列の照合順序に互換性がない場合は、異なる照合順序を持つ 2 つの文字列の連結の強制可能性値は`1`なります。
 -   列の照合順序`CAST()` 、 `CONVERT()` 、または`BINARY()`の強制値は`2`です。
 -   システム定数 ( `USER ()`または`VERSION ()`によって返される文字列) の強制値は`3`です。

diff --git a/configure-placement-rules.md b/configure-placement-rules.md
@@ -35,7 +35,7 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで
 | `Override`        | `true` / `false`  | グループ内のより小さいインデックスを持つルールを上書きするかどうか。 |
 | `StartKey`        | `string` （16進数形式） | 範囲の開始キーに適用されます。                    |
 | `EndKey`          | `string` （16進数形式） | 範囲の終了キーに適用されます。                    |
-| `Role`            | `string`          | 投票者/リーダー/フォロワー/学習者などのレプリカロール。      |
+| `Role`            | `string`          | 投票者/リーダー/フォロワー/ラーナーなどのレプリカロール。      |
 | `Count`           | `int` 、正の整数       | レプリカの数。                            |
 | `LabelConstraint` | `[]Constraint`    | ラベルに基づいてノードをフィルタリングします。            |
 | `LocationLabels`  | `[]string`        | 物理的な分離に使用されます。                     |

diff --git a/constraints.md b/constraints.md
@@ -40,8 +40,8 @@ INSERT INTO users (id,age,last_login) VALUES (NULL,123,NULL);
     Query OK, 1 row affected (0.03 sec)
 
 -   最初の`INSERT`文は、 `AUTO_INCREMENT`列に`NULL`割り当てることができるため成功します。TiDBはシーケンス番号を自動的に生成します。
--   2 番目の`INSERT`ステートメントは、 `age`列目が`NOT NULL`として定義されているため失敗します。
--   3番目の`INSERT`文は、 `last_login`列目が明示的に`NOT NULL`として定義されていないため成功します。NULL値はデフォルトで許可されています。
+-   2 番目の`INSERT`ステートメントは、 `age`列が`NOT NULL`として定義されているため失敗します。
+-   3番目の`INSERT`文は、 `last_login`列が明示的に`NOT NULL`として定義されていないため成功します。NULL値はデフォルトで許可されています。
 
 ## チェック {#check}
 

diff --git a/daily-check.md b/daily-check.md
@@ -40,7 +40,7 @@ CPU、メモリ、ディスクの使用状況を確認できます。いずれ
 -   `down-peer-region-count` ： Raftリーダーによって報告された、応答しないピアを持つリージョンの数。
 -   `empty-region-count` ：サイズが1MiB未満の空のリージョンの数。これらのリージョンは、 `TRUNCATE TABLE` / `DROP TABLE`ステートメントを実行することによって生成されます。この数が多い場合は、 `Region Merge`有効にして複数のテーブル間でリージョンをマージすることを検討してください。
 -   `extra-peer-region-count` ：追加のレプリカを持つリージョンの数。これらのリージョンはスケジューリング処理中に生成されます。
--   `learner-peer-region-count` ：学習者ピアが存在するリージョンの数。学習者ピアのソースは様々で、例えば、 TiFlashの学習者ピアや、設定済みの配置ルールに含まれる学習者ピアなどがあります。
+-   `learner-peer-region-count` ：ラーナーピアが存在するリージョンの数。ラーナーピアのソースは様々で、例えば、 TiFlashのラーナーピアや、設定済みの配置ルールに含まれるラーナーピアなどがあります。
 -   `miss-peer-region-count` ：レプリカが不足しているリージョンの数。この値は必ずしも`0`より大きいとは限りません。
 -   `offline-peer-region-count` ：ピアオフライン処理中のリージョン数。
 -   `oversized-region-count` : サイズが`region-max-size`または`region-max-keys`より大きい領域の数。