pingcap · yahonda · Aug 27, 2026 · Aug 27, 2026 · Aug 27, 2026 · Aug 27, 2026
diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md
@@ -27,7 +27,7 @@ aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-in
 - ベクトル検索インデックスが設定された列を直接削除することはサポートされていません。このような列を削除するには、まずその列のベクトル検索インデックスを削除し、次に列自体を削除します。
 - ベクトルインデックスを持つ列の型の変更はサポートされていません。
 - ベクトル検索インデックスを[見えない](/sql-statements/sql-statement-alter-index.md)に設定することはサポートされていません。
-- [保存時の暗号化](/encryption-at-rest.md)有効になっているTiFlashノード上でベクトル検索インデックスを構築することはサポートされていません。
+- [保存時の暗号化](/encryption-at-rest.md)が有効になっているTiFlashノード上でベクトル検索インデックスを構築することはサポートされていません。
 
 ## HNSWベクトルインデックスを作成する {#create-the-hnsw-vector-index}
 

diff --git a/auto-random.md b/auto-random.md
@@ -205,7 +205,7 @@ ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000;
 `AUTO_RANDOM`を使用する場合は、次の制限に注意してください。
 
 - 明示的に値を挿入するには、システム変数`@@allow_auto_random_explicit_insert`の値を`1` （デフォルトは`0` ）に設定する必要があります。データを挿入する際に、属性`AUTO_RANDOM`持つ列に明示的に値を指定することは推奨さ**れません**。そうしないと、このテーブルに自動的に割り当てられる数値が事前に使い果たされてしまう可能性があります。
-- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`サポートされません`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。
+- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`がサポートされません。`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。
 - `ALTER TABLE`を使用して`AUTO_RANDOM`属性を変更することはできません (この属性の追加や削除を含む)。
 - 最大値が列タイプの最大値に近い場合は、 `ALTER TABLE`を使用して`AUTO_INCREMENT`から`AUTO_RANDOM`に変更することはできません。
 - `AUTO_RANDOM`属性で指定された主キー列の列タイプを変更することはできません。

diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md
@@ -23,7 +23,7 @@ server_configs:
 
 > **Note:**
 >
-> Sysbenchのバージョンによっては、デフォルト値の`db-ps-mode`異なる場合があります。コマンドで明示的に指定することをお勧めします。
+> Sysbenchのバージョンによっては、デフォルト値の`db-ps-mode`が異なる場合があります。コマンドで明示的に指定することをお勧めします。
 
 ### TiKV構成 {#tikv-configuration}
 
@@ -158,7 +158,7 @@ sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 -
 
 この問題は多くの場合、プロキシの使用に関係しています。単一のTiDBサーバーに負荷をかけ、それぞれの結果を合計し、プロキシを使用した結果と比較することができます。
 
-HAproxyを例に挙げましょう。パラメータ`nbproc`を指定すると、起動できるプロセスの最大数を増やすことができます。HAproxyの最新バージョンでは、 `nbthread`と`cpu-map`サポートされています。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減します。
+HAproxyを例に挙げましょう。パラメータ`nbproc`を指定すると、起動できるプロセスの最大数を増やすことができます。HAproxyの最新バージョンでは、 `nbthread`と`cpu-map`がサポートされています。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減します。
 
 ### 同時実行性が高いのに、TiKV の CPU 使用率が低いのはなぜですか? {#under-high-concurrency-why-is-the-cpu-utilization-rate-of-tikv-still-low}
 

diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md
@@ -160,7 +160,7 @@ EXPLAIN FORMAT = "brief"
 
 ### 例2: 重複しない範囲 {#example-2-non-overlapping-ranges}
 
-別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`異なる都市の2つの異なる範囲を指定しています。
+別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、`OR`条件が異なる都市の2つの異なる範囲を指定しています。
 
 - サンフランシスコの物件、1ベッドルーム、価格`$1,500` ～ `$2,500`
 - サンディエゴの物件、1ベッドルーム、価格`$1,000` ～ `$1,500`

diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md
@@ -14,7 +14,7 @@ aliases: ['/ja/tidb/stable/three-dc-local-read/']
 
 3 つのデータセンターの展開方法については、 [1つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。
 
-TiKVノードとTiDBノードの両方に構成項目`labels`設定されている場合、同じデータセンター内のTiKVノードとTiDBノードのラベル`zone`の値は同一である必要があります。例えば、TiKVノードとTiDBノードの両方がデータセンター`dc-1`にある場合、2つのノードに以下のラベルを設定する必要があります。
+TiKVノードとTiDBノードの両方に構成項目`labels`が設定されている場合、同じデータセンター内のTiKVノードとTiDBノードのラベル`zone`の値は同一である必要があります。例えば、TiKVノードとTiDBノードの両方がデータセンター`dc-1`にある場合、2つのノードに以下のラベルを設定する必要があります。
 
 ```
 [labels]

diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md
@@ -13,7 +13,7 @@ TiDB v5.4.0より前のバージョンでは、バックアップ＆リストア
 
 バックアップタスクがクラスタに与える影響を軽減したい場合は、自動チューニング機能を有効にできます。この機能を有効にすると、TiDBはクラスタに過度の影響を与えることなく、可能な限り高速にバックアップタスクを実行します。
 
-あるいは、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)またはパラメータ`--ratelimit`を使用してバックアップ速度を制限することもできます。 `--ratelimit`設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータ`concurrency`自動的に`1`に調整されます。
+あるいは、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)またはパラメータ`--ratelimit`を使用してバックアップ速度を制限することもできます。 `--ratelimit`が設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータ`concurrency`は自動的に`1`に調整されます。
 
 ## オートチューンを使用する {#use-auto-tune}
 

diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md
@@ -33,7 +33,7 @@ summary: このドキュメントでは、ログバックアップの監視、
 | **tikv_log_backup_initial_scan_reason**                | カウンタ   | 初期スキャンがトリガーされた理由の統計。主な理由は、リーダーの交代またはリージョンバージョンの変更です。<br/> `reason :: {"leader-changed", "region-changed", "retry"}`                        |
 | **tikv_log_backup_event_handle_duration_sec**          | ヒストグラム | KVイベントの処理時間`tikv_log_backup_on_event_duration_seconds`と比較すると、この指標には内部変換の期間も含まれます。<br/> `stage :: {"to_stream_event", "save_to_temp_file"}` |
 | **tikv_log_backup_handle_kv_batch**                    | ヒストグラム | Raftstoreによって送信された KV ペア バッチのサイズのリージョンレベルの統計。                                                                                                 |
-| **tikv_log_backup_initial_scan_disk_read**             | カウンタ   | 初期スキャン中にディスクから読み取られたデータのサイズ。Linuxでは、この情報はprocfsから取得され、ブロックデバイスから実際に読み取られたデータのサイズです。このメトリックには、設定項目`initial-scan-rate-limit`適用されます。          |
+| **tikv_log_backup_initial_scan_disk_read**             | カウンタ   | 初期スキャン中にディスクから読み取られたデータのサイズ。Linuxでは、この情報はprocfsから取得され、ブロックデバイスから実際に読み取られたデータのサイズです。このメトリックには、設定項目`initial-scan-rate-limit`が適用されます。          |
 | **tikv_log_backup_incremental_scan_bytes**             | ヒストグラム | 初期スキャン中に実際に生成されたKVペアのサイズ。圧縮とリードアンプリフィケーションのため、この値は`tikv_log_backup_initial_scan_disk_read`と異なる場合があります。                                     |
 | **tikv_log_backup_skip_kv_count**                      | カウンタ   | バックアップに役立たないため、ログバックアップ中にスキップされるRaftイベントの数。                                                                                               |
 | **tikv_log_backup_errors**                             | カウンタ   | ログバックアップ中に再試行または無視できるエラー。<br/> `type :: ErrorType`                                                                                        |

diff --git a/character-set-gbk.md b/character-set-gbk.md
@@ -7,7 +7,7 @@ summary: このドキュメントでは、GBK 文字セットの TiDB サポー
 
 TiDBはv5.4.0以降、GBK文字セットをサポートしています。このドキュメントでは、TiDBのGBK文字セットのサポートと互換性に関する情報を提供します。
 
-TiDB v6.0.0以降、デフォルトで[照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)有効になります。TiDB GBK文字セットのデフォルトの照合照合順序は`gbk_chinese_ci`で、これはMySQLと一致しています。
+TiDB v6.0.0以降、デフォルトで[照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)が有効になります。TiDB GBK文字セットのデフォルトの照合照合順序は`gbk_chinese_ci`で、これはMySQLと一致しています。
 
 ```sql
 SHOW CHARACTER SET WHERE CHARSET = 'gbk';

diff --git a/check-before-deployment.md b/check-before-deployment.md
@@ -153,7 +153,7 @@ TiDBの一部の操作では、サーバーへの一時ファイルの書き込
 
     > **Note:**
     >
-    > ディレクトリが存在しない場合は、TiDB は起動時に自動的に作成します。ディレクトリの作成に失敗した場合、または TiDB がそのディレクトリに対する読み取りおよび書き込み権限を持っていない場合、実行時に[`Fast Online DDL`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)無効になります。
+    > ディレクトリが存在しない場合は、TiDB は起動時に自動的に作成します。ディレクトリの作成に失敗した場合、または TiDB がそのディレクトリに対する読み取りおよび書き込み権限を持っていない場合、実行時に[`Fast Online DDL`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)が無効になります。
 
 ## 対象マシンのファイアウォールサービスを確認する {#check-the-firewall-service-of-target-machines}
 

diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md
@@ -49,7 +49,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、
 
 プロファイリングを開始する前に、プロファイリング期間を変更できます。この期間はプロファイリングに必要な時間によって決まり、デフォルトでは30秒です。30秒の期間は完了まで30秒かかります。
 
-[継続的なプロファイリング](/dashboard/continuous-profiling.md)有効になっているクラスターでは、手動プロファイリングを開始できません。現時点でのパフォーマンスデータを表示するには、 [継続的なプロファイリングページ](/dashboard/continuous-profiling.md#access-the-page)で最新のプロファイリング結果をクリックしてください。
+[継続的なプロファイリング](/dashboard/continuous-profiling.md)が有効になっているクラスターでは、手動プロファイリングを開始できません。現時点でのパフォーマンスデータを表示するには、 [継続的なプロファイリングページ](/dashboard/continuous-profiling.md#access-the-page)で最新のプロファイリング結果をクリックしてください。
 
 ## プロファイリングステータスを表示する {#view-profiling-status}
 

diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md
@@ -57,7 +57,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ
 
     - 時間ウィンドウの範囲が 10分から 24時間の範囲外の場合、次のエラーが表示されます`ERROR 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s` 。
 
-    - [実際の作業負荷に基づく容量推定](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload)機能の監視メトリックには、 `tikv_cpu_quota` 、 `tidb_server_maxprocs` 、 `resource_manager_resource_unit` 、 `process_cpu_usage`含まれます。CPUクォータ監視データが空の場合、対応する監視メトリック名（例： `Error 1105 (HY000): There is no CPU quota metrics, metrics 'tikv_cpu_quota' is empty` ）にエラーが発生します。
+    - [実際の作業負荷に基づく容量推定](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload)機能の監視メトリックには、 `tikv_cpu_quota` 、 `tidb_server_maxprocs` 、 `resource_manager_resource_unit` 、 `process_cpu_usage`が含まれます。CPUクォータ監視データが空の場合、対応する監視メトリック名（例： `Error 1105 (HY000): There is no CPU quota metrics, metrics 'tikv_cpu_quota' is empty` ）にエラーが発生します。
 
     - 時間枠内のワークロードが低すぎる場合、または`resource_manager_resource_unit`と`process_cpu_usage`監視データが欠落している場合は、エラーが報告されます`Error 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; please select another time window with higher workload, or calibrate resource by hardware instead`また、TiKVはmacOSのCPU使用率を監視しないため、実際のワークロードに基づく容量推定をサポートしておらず、このエラーも報告されます。
 

diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md
@@ -225,7 +225,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提
     次のような場合は、この設定が小さすぎるかどうかを確認する必要があります。
 
     - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** &gt; **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。
-    - そして、 `cachePrepStmts=true`設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`存在することがわかった。
+    - そして、 `cachePrepStmts=true`が設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`が存在することがわかった。
 
 - **prepStmtCacheSize**
 

diff --git a/develop/dev-guide-sample-application-python-sqlalchemy.md b/develop/dev-guide-sample-application-python-sqlalchemy.md
@@ -67,7 +67,7 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。
 
 > **Note:**
 >
-> 現在、 TiDB Cloud Starterインスタンスには制限があります。5分間アクティブな接続がない場合、インスタンスはシャットダウンし、すべての接続が閉じられます。そのため、 TiDB Cloud Starterインスタンスで SQLAlchemy を使用する場合、プールされた接続で`OperationalError`のような`Lost connection to MySQL server during query`や`MySQL Connection not available`発生する可能性があります。このエラーを回避するには、 `pool_recycle`パラメータを`300`に設定してください。詳細については、SQLAlchemy ドキュメントの[接続切れへの対処](https://docs.sqlalchemy.org/en/20/core/pooling.html#dealing-with-disconnects)を参照してください。
+> 現在、 TiDB Cloud Starterインスタンスには制限があります。5分間アクティブな接続がない場合、インスタンスはシャットダウンし、すべての接続が閉じられます。そのため、 TiDB Cloud Starterインスタンスで SQLAlchemy を使用する場合、プールされた接続で`OperationalError`のような`Lost connection to MySQL server during query`や`MySQL Connection not available`が発生する可能性があります。このエラーを回避するには、 `pool_recycle`パラメータを`300`に設定してください。詳細については、SQLAlchemy ドキュメントの[接続切れへの対処](https://docs.sqlalchemy.org/en/20/core/pooling.html#dealing-with-disconnects)を参照してください。
 
 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。
 

diff --git a/dm/table-selector.md b/dm/table-selector.md
@@ -14,7 +14,7 @@ summary: データ移行のテーブルルーティング、 binlogイベント
 - アスタリスク文字（ `*` 、「スター」とも呼ばれる）
 
     - `*` 0文字以上の文字に一致します。例えば、 `doc*` `doc`と`document`に一致しますが、 `dodo`は一致しません。
-    - `*`単語の末尾にのみ配置できます。例えば、 `doc*`サポートされていますが、 `do*c`サポートされていません。
+    - `*`単語の末尾にのみ配置できます。例えば、 `doc*`がサポートされていますが、 `do*c`はサポートされていません。
 
 - 疑問符（ `?` ）
 

diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md
@@ -2354,7 +2354,7 @@ TiDB と MySQL 間の`match_type`の値オプションは次のとおりです
 
 - TiDB の値オプションは`"c"` 、 `"i"` 、 `"m"` 、 `"s"`であり、MySQL の値オプションは`"c"` 、 `"i"` 、 `"m"` 、 `"n"` 、 `"u"`です。
 
-- TiDBの`"s"`はMySQLの`"n"`に相当します。TiDBで`"s"`設定されている場合、 `.`は行末文字（ `\n` ）にも一致します。
+- TiDBの`"s"`はMySQLの`"n"`に相当します。TiDBで`"s"`が設定されている場合、 `.`は行末文字（ `\n` ）にも一致します。
 
     たとえば、MySQL の`SELECT REGEXP_LIKE(a, b, "n") FROM t1` TiDB の`SELECT REGEXP_LIKE(a, b, "s") FROM t1`と同じです。