pingcap · yahonda · Aug 27, 2026 · Aug 28, 2026
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -150,7 +150,7 @@ git push -u origin new-branch-name # "-u" is used to track the remote branch fro
 変更が以下のいずれかの状況に当てはまる場合は、**影響を受けるリリース ブランチとマスターを選択してください**。
 
 - 特定のバージョンに関連する機能の動作の変更が含まれます。
-- 構成項目またはシステム変数のデフォルト値の変更など、互換性の変更が含まれます。
+- 設定項目またはシステム変数のデフォルト値の変更など、互換性の変更が含まれます。
 - 表示エラーを解決するためにフォーマットを修正します
 - 壊れたリンクを修正
 

diff --git a/agg-distinct-optimization.md b/agg-distinct-optimization.md
@@ -29,7 +29,7 @@ mysql> explain SELECT DISTINCT a from t;
 
 <CustomContent platform="tidb">
 
-TiDB の[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distinct_agg_push_down)システム変数または[`distinct-agg-push-down`](/tidb-configuration-file.md#distinct-agg-push-down)構成項目は、個別の集計クエリを書き換えて TiKV またはTiFlashコプロセッサーにプッシュするかどうかを制御します。
+TiDB の[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distinct_agg_push_down)システム変数または[`distinct-agg-push-down`](/tidb-configuration-file.md#distinct-agg-push-down)設定項目は、個別の集計クエリを書き換えて TiKV またはTiFlashコプロセッサーにプッシュするかどうかを制御します。
 
 </CustomContent>
 

diff --git a/alert-rules.md b/alert-rules.md
@@ -412,7 +412,7 @@ summary: TiDB クラスターのアラートルールについて学習します
 
     - [**TiKV詳細**&gt; **PD**ダッシュボード](/grafana-tikv-dashboard.md#pd)を監視し、ストア低速スコアのメトリックを確認します。メトリック値が80を超えるノードを特定し、低速ノードとして検出します。
     - [**TiKV-詳細**&gt; **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。
-    - レイテンシーのタイムアウト制限を増やすには、 [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)構成項目を大きな値に設定します。
+    - レイテンシーのタイムアウト制限を増やすには、 [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)設定項目を大きな値に設定します。
     - アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)を参照してください。
 
 ## TiKVアラートルール {#tikv-alert-rules}

diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md
@@ -98,7 +98,7 @@ config set max-merge-region-keys 540000
 config set merge-schedule-limit 8
 ```
 
-詳細については、 [リージョン結合](https://tikv.org/docs/4.0/tasks/configure/region-merge/)および[PD設定ファイル](/pd-configuration-file.md#schedule)の次の3つの構成パラメータを参照してください。
+詳細については、 [リージョン結合](https://tikv.org/docs/4.0/tasks/configure/region-merge/)および[PD設定ファイル](/pd-configuration-file.md#schedule)の次の3つの設定パラメータを参照してください。
 
 - [`max-merge-region-size`](/pd-configuration-file.md#max-merge-region-size)
 - [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys)

diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md
@@ -289,7 +289,7 @@ v3.0.4およびv2.1.16以前では、特定の状況（主にテーブルの削
 
 ### TiKVノードのトラブルシューティング {#troubleshoot-tikv-node}
 
-TiKV ノードに障害が発生した場合、PD はデフォルトで、対応するノードを 30分後 (構成項目`max-store-down-time`でカスタマイズ可能) に**ダウン**状態に設定し、関係するリージョンのレプリカを再調整します。
+TiKV ノードに障害が発生した場合、PD はデフォルトで、対応するノードを 30分後 (設定項目`max-store-down-time`でカスタマイズ可能) に**ダウン**状態に設定し、関係するリージョンのレプリカを再調整します。
 
 実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。
 

diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md
@@ -30,7 +30,7 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり
 
 ## リージョンの数を制御する {#control-the-number-of-regions}
 
-多数のテーブル (たとえば、100,000 個以上) を作成する必要がある場合は、TiDB 構成項目[`split-table`](/tidb-configuration-file.md#split-table)を`false`に設定してリージョンの数を減らし、TiKV のメモリ負荷を軽減することをお勧めします。
+多数のテーブル (たとえば、100,000 個以上) を作成する必要がある場合は、TiDB 設定項目[`split-table`](/tidb-configuration-file.md#split-table)を`false`に設定してリージョンの数を減らし、TiKV のメモリ負荷を軽減することをお勧めします。
 
 ## キャッシュを構成する {#configure-caches}
 
@@ -76,7 +76,7 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり
 
 SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに接続して自身のテナント（データベース）内のデータを操作します。多数の接続をサポートするには、次の点に留意してください。
 
-- より多くの同時リクエストをサポートするには、TiDB 構成項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。
+- より多くの同時リクエストをサポートするには、TiDB 設定項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。
 - TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。
 - `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`ステートメントが長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。
 

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/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md
@@ -28,7 +28,7 @@ PDとTiKVはどちらもディスク上に情報を保存するため、ディ
 
 ## パラメータ調整 {#parameter-adjustment}
 
-上の画像では、デフォルトのスレッドプール構成とバックグラウンドタスクへのリソース割り当てが、十分なリソースを持つマシン向けに設定されているため、パフォーマンスのジッターが発生しています。ハイブリッド展開シナリオでは、リソースが複数のコンポーネント間で共有されるため、構成パラメータによってリソース消費を制限する必要があります。
+上の画像では、デフォルトのスレッドプール構成とバックグラウンドタスクへのリソース割り当てが、十分なリソースを持つマシン向けに設定されているため、パフォーマンスのジッターが発生しています。ハイブリッド展開シナリオでは、リソースが複数のコンポーネント間で共有されるため、設定パラメータによってリソース消費を制限する必要があります。
 
 このテストの最終的なクラスター構成は次のとおりです。
 

diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md
@@ -75,7 +75,7 @@ TiDB BRは以下の機能を提供します。
 
 #### バックアップのパフォーマンスとTiDBクラスタへの影響 {#backup-performance-and-impact-on-tidb-clusters}
 
-- クラスタのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスタに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスタを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV構成項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスタに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 [バックアップのパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup)を参照してください。
+- クラスタのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスタに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスタを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスタに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 [バックアップのパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup)を参照してください。
 - ログバックアップタスクのみの場合、クラスタへの影響は約5%です。ログバックアップは、3～5分ごとに最後の更新後に生成されたすべての変更をバックアップストレージにフラッシュするため、**最短5分のリカバリポイント目標（RPO）を実現できます**。
 
 ### バックアップデータを復元する {#restore-backup-data}

diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md
@@ -23,7 +23,7 @@ TiDB v5.4.0より前のバージョンでは、バックアップ＆リストア
 >
 > v5.3.xからv5.4.0以降のバージョンにアップグレードするクラスターでは、自動チューニング機能はデフォルトで無効になっています。手動で有効にする必要があります。
 
-自動調整機能を手動で有効にするには、TiKV 構成項目[`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-new-in-v540)を`true`に設定する必要があります。
+自動調整機能を手動で有効にするには、TiKV 設定項目[`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-new-in-v540)を`true`に設定する必要があります。
 
 TiKVは自動チューニング機能の動的な設定をサポートしています。この機能は、クラスターを再起動せずに有効化または無効化できます。自動チューニング機能を動的に有効化または無効化するには、次のコマンドを実行します。
 

diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md
@@ -17,7 +17,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ
 
 増分バックアップでは、テーブル名の一括変更はサポートされていません。増分バックアップ中にテーブル名の一括変更が行われた場合、データの復元が失敗する可能性があります。テーブル名の一括変更後に完全バックアップを実行し、復元時に最新の完全バックアップを使用して増分データを置き換えることをお勧めします。
 
-バージョン8.3.0以降、増分バックアップと後続のログバックアップの互換性を制御するための構成パラメータ`--allow-pitr-from-incremental`が導入されました。デフォルト値は`true`で、増分バックアップと後続のログバックアップの互換性があることを意味します。
+バージョン8.3.0以降、増分バックアップと後続のログバックアップの互換性を制御するための設定パラメータ`--allow-pitr-from-incremental`が導入されました。デフォルト値は`true`で、増分バックアップと後続のログバックアップの互換性があることを意味します。
 
 - デフォルト値`true`ままにしておくと、増分リストアを開始する前に、再生が必要なDDLが厳密にチェックされます。このモードでは、 `ADD INDEX` 、 `MODIFY COLUMN` 、 `REORG PARTITION`まだサポートされていません。増分バックアップとログバックアップを併用する場合は、増分バックアッププロセス中に、前述のDDLが存在しないことを確認してください。そうでない場合、これら3つのDDLを正しく再生できません。
 

diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md
@@ -154,7 +154,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ
 テストシナリオ 1 ( [TiDB Cloud](https://tidbcloud.com)上) は次のとおりです。
 
 - TiKVノード数（8コア、16GBメモリ）: 21
-- TiKV構成項目`import.num-threads` ：8
+- TiKV設定項目`import.num-threads` ：8
 - BRコマンドオプション`pitr-concurrency` ：128
 - リージョン数: 183,000
 - クラスターに作成された新しいログデータ: 10 GB/時間
@@ -163,7 +163,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ
 テスト シナリオ 2 (TiDB Self-Managed 上) は次のとおりです。
 
 - TiKVノード数（8コア、64GBメモリ）: 6
-- TiKV構成項目`import.num-threads` ：8
+- TiKV設定項目`import.num-threads` ：8
 - BRコマンドオプション`pitr-concurrency` ：128
 - リージョン数: 50,000
 - クラスターに作成された新しいログデータ: 10 GB/時間

diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md
@@ -218,7 +218,7 @@ tiup br restore full \
 
 以下の方法を使用すると、バックアップタスクがクラスタのパフォーマンスに与える影響を手動で制御できます。ただし、これらの2つの方法は、バックアップタスクがクラスタに与える影響を軽減する一方で、バックアップタスクの速度も低下させます。
 
-- 推奨される方法: TiKV 構成パラメータ[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整します。このパラメータは、バックアップタスクで使用されるワーカースレッドの数を制御します。バックアップは CPU 負荷の高い操作であるため、このパラメータを調整することで TiKV の CPU 使用率をより正確に制御でき、リソースの分離と予測性を向上させることができます。ほとんどのシナリオでは、 `num-threads`を調整するだけで、バックアップがクラスタに与える影響を制限できます。内部テストでは、スレッド数を`8`以下に設定し、クラスタ全体の CPU 使用率が 60% 未満に維持されている場合、バックアップがフォアグラウンド ワークロードに与える影響はごくわずかであることが示されています。
+- 推奨される方法: TiKV 設定パラメータ[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整します。このパラメータは、バックアップタスクで使用されるワーカースレッドの数を制御します。バックアップは CPU 負荷の高い操作であるため、このパラメータを調整することで TiKV の CPU 使用率をより正確に制御でき、リソースの分離と予測性を向上させることができます。ほとんどのシナリオでは、 `num-threads`を調整するだけで、バックアップがクラスタに与える影響を制限できます。内部テストでは、スレッド数を`8`以下に設定し、クラスタ全体の CPU 使用率が 60% 未満に維持されている場合、バックアップがフォアグラウンド ワークロードに与える影響はごくわずかであることが示されています。
 
 - 代替方法: `backup.num-threads`を既に小さな値 (たとえば`1` ) に設定しているが、バックアップがクラスタに与える影響をさらに軽減したい場合は、 `--ratelimit`パラメータの使用を検討してください。このオプションは、バックアップファイルを外部ストレージに書き込むために使用される帯域幅を MiB/s で制限します。実際のレート制限効果は、圧縮データのサイズによって異なることに注意してください。詳細については、ログの`backup data size (after compressed)`フィールドを参照してください。 `--ratelimit`が有効になっている場合、 BR は自動的に`--concurrency`を`1`に設定して、同時リクエストの数を減らします。