pingcap · yahonda · Jul 22, 2026
diff --git a/auto-increment.md b/auto-increment.md
@@ -84,7 +84,7 @@ mysql> SELECT * FROM t;
 
 上記の使用法はMySQLの`AUTO_INCREMENT`と同じです。ただし、暗黙的に割り当てられる具体的な値に関しては、TiDBはMySQLとは大きく異なります。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装します。
 

diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md
@@ -13,7 +13,7 @@ TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポ
 
 TiDBクラスタが大規模で、障害発生後に再度リストアを行う余裕がない場合は、チェックポイントリストア機能を使用できます。brコマンドラインツール（以下、 `br` ）は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近いリカバリ進捗ポイントを使用できます。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)参照してください。
 

diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md
@@ -34,7 +34,7 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2
 
     クラスタが現時点で安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタを検査する必要があります。PingCAP Clinicが提供するローカルおよびサーバー側のクイックチェック機能を使用することで、クラスタの潜在的な健全性リスクを特定できます。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 このセクションでは、Diag がクラスターから診断データを収集する実装原則について説明します。
 

diff --git a/configure-load-base-split.md b/configure-load-base-split.md
@@ -20,7 +20,7 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ
 -   リージョンを均等に分割することは、必ずしも最適な選択とは限りません。リクエストが少数のキーに集中する可能性があるためです。このような場合、均等分割後もホットスポットがいずれかのリージョンに残る可能性があり、目的を達成するには複数回の均等分割が必要になる場合があります。
 -   人間の介入はタイムリーでも簡単でもない。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 Load Base Splitは、統計情報に基づいてリージョンを自動的に分割します。読み取り負荷またはCPU使用率が10秒間継続的にしきい値を超えるリージョンを特定し、これらのリージョンを適切な位置で分割します。分割位置の選択にあたっては、分割後の両リージョンのアクセス負荷のバランスを取り、リージョン間のアクセスを回避しようとします。
 

diff --git a/configure-store-limit.md b/configure-store-limit.md
@@ -7,7 +7,7 @@ summary: ストア制限の機能について学びます。
 
 ストア制限はPDの機能です。様々なシナリオにおいてパフォーマンスを向上させるために、スケジューリング速度をより細かく制御できるように設計されています。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 PDはオペレータ単位でスケジューリングを実行します。オペレータには複数のスケジューリング操作が含まれる場合があります。例：
 

diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md
@@ -11,7 +11,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを
 
 特別な状況に対処したり、テーブル スキーマの不一致によって発生する移行の中断を処理したりするために、DM は内部テーブル スキーマを取得、変更、および削除する`binlog-schema`コマンドを提供します。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 内部テーブル スキーマは次のソースから取得されます。
 
@@ -44,7 +44,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを
 >
 > `binlog-schema`コマンドは DM v6.0 以降のバージョンでのみサポートされます。それ以前のバージョンでは、 `operate-schema`コマンドを使用する必要があります。
 
-## 指示 {#command}
+## コマンド {#command}
 
 ```bash
 help binlog-schema

diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md
@@ -105,7 +105,7 @@ ALTER TABLE `tbl00` ADD COLUMN `Age` INT DEFAULT -1;
 
 この時点で、 `DEFAULT 0`と`DEFAULT -1`互いに互換性がないため、 `tbl00`の`Age`列は不整合になります。このような状況では、DMはエラーを報告しますが、データの不整合を手動で修正する必要があります。
 
-## 実施原則 {#implementation-principle}
+## 実装原理 {#implementation-principle}
 
 楽観的モードでは、DMワーカーは上流からDDL文を受信すると、更新されたテーブルスキーマをDMマスターに転送します。DMワーカーは各シャードテーブルの現在のスキーマを追跡し、DMマスターはこれらのスキーマを、各シャードテーブルのDML文と互換性のある複合スキーマにマージします。その後、DMマスターは対応するDDL文を下流に移行します。DML文は下流に直接移行されます。
 

diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md
@@ -14,7 +14,7 @@ DMはシャーディングDDLロックを使用して、操作が正しい順序
 > -   コマンドによってもたらされる可能性のある影響を完全に認識し、それを受け入れられる場合を除き、 `shard-ddl-lock unlock`使用しないでください。
 > -   異常な DDL ロックを手動で処理する前に、DM [シャードマージの原則](/dm/feature-shard-merge-pessimistic.md#principles)必ず読んでください。
 
-## 指示 {#command}
+## コマンド {#command}
 
 ### `shard-ddl-lock` {#shard-ddl-lock}
 

diff --git a/pd-control.md b/pd-control.md
@@ -105,7 +105,7 @@ tiup ctl:v<CLUSTER_VERSION> pd -u https://127.0.0.1:2379 --cacert="path/to/ca" -
 -   バージョン情報を出力して終了します
 -   デフォルト: false
 
-## 指示 {#command}
+## コマンド {#command}
 
 ### `cluster` {#cluster}
 

diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md
@@ -60,7 +60,7 @@ FlashbackToNewName ::=
     FLASHBACK TABLE t TO t1;
     ```
 
-## 実施原則 {#implementation-principle}
+## 実装原理 {#implementation-principle}
 
 テーブルを削除する際、TiDBはテーブルメタデータのみを削除し、削除対象のテーブルデータ（行データとインデックスデータ）を`mysql.gc_delete_range`テーブルに書き込みます。TiDBのバックグラウンドにあるGCワーカーは、GCの有効期間を超えたキーを`mysql.gc_delete_range`テーブルから定期的に削除します。
 

diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md
@@ -75,7 +75,7 @@ NUM ::= intLit
 
     このメソッドは、 `DDL JOB ID`を介して削除されたテーブルを回復します。対応するDDLジョブが`DROP TABLE`タイプでない場合は、エラーが発生します。
 
-## 実施原則 {#implementation-principle}
+## 実装原理 {#implementation-principle}
 
 テーブルを削除する際、TiDBはテーブルメタデータのみを削除し、削除対象のテーブルデータ（行データとインデックスデータ）を`mysql.gc_delete_range`テーブルに書き込みます。TiDBのバックグラウンドにあるGCワーカーは、GCの有効期間を超えたキーを`mysql.gc_delete_range`テーブルから定期的に削除します。
 

diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md
@@ -104,7 +104,7 @@ v8.1.0以降、タスク実行中に新しいノードが追加された場合
 > -   バージョンv7.4.0からv8.0.0まで、複数のTiDBノードを持つクラスターでは、2つ以上のTiDBノードで[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)から`background`設定することを強くお勧めします。この変数を1つのTiDBノードにのみ設定した場合、そのノードが再起動または障害を起こした場合、タスクは`tidb_service_scope = ''`が設定されているTiDBノードに再スケジュールされ、これらのTiDBノードで実行されているアプリケーションに影響を及ぼします。
 > -   分散タスクの実行中、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)構成への変更は現在のタスクには適用されませんが、次のタスクからは適用されます。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 DXF のアーキテクチャは次のとおりです。
 

diff --git a/tidb-global-sort.md b/tidb-global-sort.md
@@ -75,7 +75,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ
 >
 > [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)については、 [`CLOUD_STORAGE_URI`](/sql-statements/sql-statement-import-into.md#withoptions)オプションを使用してクラウドストレージのパスを指定することもできます。 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)と`CLOUD_STORAGE_URI`両方に有効なクラウドストレージのパスが設定されている場合、 `CLOUD_STORAGE_URI`の設定が[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)に有効になります。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 グローバルソート機能のアルゴリズムは次のとおりです。
 

diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md
@@ -15,7 +15,7 @@ MPPクエリを処理する際、TiDBはクエリを1つ以上のMPPタスクに
 
 高い同時実行性が必要なシナリオで TiFlash の処理能力を向上させるには、 TiFlashに MPP タスク スケジューラを導入する必要があります。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 [背景](#background)で述べたように、 TiFlashタスクスケジューラを導入する当初の目的は、MPP クエリ実行中に使用されるスレッド数を制御することです。シンプルなスケジューリング戦略は、 TiFlash が要求できる最大スレッド数を指定することです。スケジューラは、各 MPP タスクについて、システムで現在使用されているスレッド数と、MPP タスクが使用すると予想されるスレッド数に基づいて、その MPP タスクをスケジュールできるかどうかを判断します。
 

diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md
@@ -12,7 +12,7 @@ TiKV MVCCインメモリエンジンは、以下のシナリオに適してい
 -   頻繁に更新または削除されるレコードを照会する必要があるアプリケーション。
 -   TiDBに履歴バージョンをより長い期間（例えば24時間）保持するために、 [`tidb_gc_life_time`](/garbage-collection-configuration.md#garbage-collection-configuration)調整する必要があるアプリケーション。
 
-## 実施原則 {#implementation-principles}
+## 実装原理 {#implementation-principles}
 
 TiKV MVCCインメモリエンジンは、最新の書き込み済みMVCCバージョンをメモリにキャッシュし、TiDBとは独立したMVCC GCメカニズムを実装しています。これにより、メモリ内のMVCCバージョンに対して高速なGCを実行でき、クエリ中にスキャンされるバージョンの数を削減することで、リクエストのレイテンシーを低減し、CPUオーバーヘッドを削減します。