diff --git a/ai/integrations/vector-search-auto-embedding-cohere.md b/ai/integrations/vector-search-auto-embedding-cohere.md
index f746cc069af73..93b1d34c34fe5 100644
--- a/ai/integrations/vector-search-auto-embedding-cohere.md
+++ b/ai/integrations/vector-search-auto-embedding-cohere.md
@@ -72,7 +72,7 @@ CREATE TABLE sample (
 
 > **Note:**
 >
-> -   Cohere埋め込みモデルの場合、テーブルを定義する際に、{{ `input_type` `EMBED_TEXT()` }を指定する必要があります。例えば、 `'{"input_type": "search_document", "input_type@search": "search_query"}'`は、データ挿入時に`input_type`が`search_document`に設定され、ベクトル検索時に`search_query`が自動的に適用されることを意味します。
+> -   Cohere埋め込みモデルの場合、テーブルを定義する際に、 `EMBED_TEXT()`関数で`input_type`を指定する必要があります。例えば、 `'{"input_type": "search_document", "input_type@search": "search_query"}'`は、データ挿入時に`input_type`が`search_document`に設定され、ベクトル検索時に`search_query`が自動的に適用されることを意味します。
 > -   `@search`サフィックスは、そのフィールドがベクトル検索クエリの実行時のみ有効であることを示しています。そのため、クエリを作成する際に`input_type`を再度指定する必要はありません。
 
 データ挿入とデータ照会：
diff --git a/ai/quickstart-via-sql.md b/ai/quickstart-via-sql.md
index f423ca37c1413..e5c07619fc64c 100644
--- a/ai/quickstart-via-sql.md
+++ b/ai/quickstart-via-sql.md
@@ -143,7 +143,7 @@ SELECT * FROM embedded_documents;
 
 この例では、検索語は「泳ぐ動物」であり、それに対応するベクトル埋め込みは`[1,2,3]`であると想定されています。実際のアプリケーションでは、埋め込みモデルを使用して、ユーザーの検索語をベクトル埋め込みに変換する必要があります。
 
-次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `[1,2,3]`計算してソートすることにより、 `vec_cosine_distance` } に最も近い上位 3 つのドキュメントを特定します。
+次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `vec_cosine_distance` ) を計算してソートすることにより、 `[1,2,3]`に最も近い上位 3 つのドキュメントを特定します。
 
 ```sql
 SELECT id, document, vec_cosine_distance(embedding, '[1,2,3]') AS distance
diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md
index 3eed6a0aea860..3ca2ea20ce2a3 100644
--- a/br/br-checkpoint-restore.md
+++ b/br/br-checkpoint-restore.md
@@ -15,15 +15,15 @@ TiDBクラスタが大規模で、障害発生後に再度リストアを行う
 
 ## 実施原則 {#implementation-principles}
 
-チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)参照してください。
+チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)を参照してください。
 
 ### スナップショットの復元 {#snapshot-restore}
 
-スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。3 `br` 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`この範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。
+スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。 `br`は、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`はこの範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。
 
-`br`復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`チェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。
+`br`は復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`はチェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。
 
-`br`リストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 `br`以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。
+`br`がリストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 `br`は以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。
 
 MVCC (Multi-Version Concurrency Control) メカニズムを使用しているため、指定されたタイムスタンプを持つデータを順序なしで繰り返し書き込むことができます。
 
@@ -35,27 +35,27 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた
 
 スナップショットバックアップファイルとは異なり、ログバックアップファイルの範囲は重複する可能性があります。そのため、キー範囲を復旧進捗メタデータとして直接使用することはできません。また、ログバックアップファイルの数が多すぎる場合もあります。ただし、各ログバックアップファイルは、ログバックアップメタデータ内で固定の位置を持ちます。つまり、ログバックアップメタデータ内の一意の位置を、復旧進捗メタデータとして各ログバックアップファイルに割り当てることができます。
 
-ログバックアップメタデータには、ファイルメタデータの配列が含まれています。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されるファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、トリプル`(log backup metadata name, file metadata array offset, log backup file array offset)` `br`してログバックアップファイルを一意に識別できます。
+ログバックアップメタデータには、ファイルメタデータの配列が含まれています。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されるファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、`br`は`(ログバックアップメタデータ名、ファイルメタデータ配列オフセット、ログバックアップファイル配列オフセット)`の3つの要素の組を使用してログバックアップファイルを一意に識別できます。
 
 ## 使用制限 {#usage-limitations}
 
-チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録することはできません。詳細については、以下のセクションで説明します。
+チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録できるわけではありません。詳細については、以下のセクションで説明します。
 
 ### GCは一時停止されます {#gc-will-be-paused}
 
-ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`ログの復元中にGCを一時停止します。3 `br`途中で終了した場合、GCは一時停止状態のままになります。
+ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`はログの復元中にGCを一時停止します。`br`が途中で終了した場合、GCは一時停止状態のままになります。
 
 ログの復元が完了すると、GCは手動で起動することなく自動的に再起動されます。ただし、復元を続行しない場合は、以下の手順でGCを手動で有効にすることができます。
 
-`br` GCを一時停止する原理は、 `SET config tikv gc.ratio-threshold = -1.0`実行して`gc.ratio-threshold`負の値に設定し、GCを一時停止することです。 [`gc.ratio-threshold`](/tikv-configuration-file.md#ratio-threshold)の値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 `SET config tikv gc.ratio-threshold = 1.1`実行します。
+`br`がGCを一時停止する原理は、 `SET config tikv gc.ratio-threshold = -1.0`を実行して`gc.ratio-threshold`を負の値に設定し、GCを一時停止することです。 [`gc.ratio-threshold`](/tikv-configuration-file.md#ratio-threshold)の値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 `SET config tikv gc.ratio-threshold = 1.1`を実行します。
 
 ### 一部のデータは再度復元する必要があります {#some-data-needs-to-be-restored-again}
 
-`br`復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。
+`br`は復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。
 
--   中断の原因がエラーである場合、 `br`終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。
+-   中断の原因がエラーである場合、 `br`は終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。
 
--   `br`プロセスがシステムによって中断された場合、 `br`外部ストレージに復元されたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。
+-   `br`プロセスがシステムによって中断された場合、 `br`は外部ストレージに復元されたデータのメタ情報を永続化できません。`br`は30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。
 
 ### 復元中にクラスタデータを変更しないようにする {#avoid-modifying-cluster-data-during-the-restore}
 
@@ -63,43 +63,43 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた
 
 ### クロスメジャーバージョンのチェックポイントリカバリは推奨されません {#cross-major-version-checkpoint-recovery-is-not-recommended}
 
-メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用して`br`リカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。
+メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用して`br`のリカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。
 
 ## 実装の詳細: チェックポイントデータを下流のクラスタに保存する {#implementation-details-store-checkpoint-data-in-the-downstream-cluster}
 
 > **Note:**
 >
-> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータのストレージを指定できます。
+> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータのストレージを指定できます。
 
 チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。
 
 ### スナップショットの復元 {#snapshot-restore}
 
-初期復元中に、 `br`ターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。
+初期復元中に、 `br`はターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。
 
-復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。
+復元が失敗した場合は、同じコマンドを使用して再試行できます。`br`は`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。
 
-復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`エラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。
+復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`はエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。
 
 ### PITR復元 {#pitr-restore}
 
-[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。
+[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)はスナップショットの復元フェーズとログの復元フェーズで構成されます。
 
-初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。
+初期リストアでは、 `br`はスナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts`を`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。
 
-初期復元中にログ復元フェーズに入ると、 `br`ターゲットクラスターに`__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ `start-ts`と`restored-ts` ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`エラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。
+初期復元中にログ復元フェーズに入ると、 `br`はターゲットクラスターに`__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ `start-ts`と`restored-ts` ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。
 
-初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。mysql.tidb_pitr_id_map**からデータを恣意的に削除すると`mysql.tidb_pitr_id_map` PITRリストアデータの不整合が発生する可能性があります。**
+初期リストア中のログリストアフェーズに入る前に、 `br`が`restored-ts`時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。 **`mysql.tidb_pitr_id_map`からデータを恣意的に削除すると、PITRリストアデータの不整合が発生する可能性があります。**
 
 > **Note:**
 >
-> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`存在しない場合、 `pitr_id_map`データがログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。
+> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`が存在しない場合、 `pitr_id_map`データがログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。
 
 ## 実装の詳細: チェックポイントデータを外部ストレージに保存する {#implementation-details-store-checkpoint-data-in-the-external-storage}
 
 > **Note:**
 >
-> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータの外部ストレージを指定できます。例：
+> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータの外部ストレージを指定できます。例：
 >
 > ```shell
 > ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"
@@ -107,9 +107,9 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた
 
 外部ストレージでは、チェックポイント データのディレクトリ構造は次のようになります。
 
--   ルート パス`restore-{downstream-cluster-ID}` 、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。
+-   ルート パス`restore-{downstream-cluster-ID}`は、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。
 -   パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。
--   パス`restore-{downstream-cluster-ID}/sst` 、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。
+-   パス`restore-{downstream-cluster-ID}/sst`は、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。
 -   パス`restore-{downstream-cluster-ID}/snapshot`は、スナップショット復元フェーズ中にチェックポイント データが保存されます。
 
 <!---->
@@ -141,21 +141,21 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた
 
 ### スナップショットの復元 {#snapshot-restore}
 
-初期復元中に、 `br`指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パス`br`作成します。このパスには、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSが記録されます。
+初期復元中に、 `br`は指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パスを作成します。このパスには、 `br`がチェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSを記録します。
 
-復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` 、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。
+復元が失敗した場合は、同じコマンドを使用して再試行できます。`br`は、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。
 
-復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、エラーコード`br`報告されます。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。
+復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`はエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。
 
 ### PITR復元 {#pitr-restore}
 
-[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。
+[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)はスナップショットの復元フェーズとログの復元フェーズで構成されます。
 
-初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。
+初期リストアでは、 `br`はスナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。
 
-初期復元中にログ復元フェーズに入ると、 `br`​​指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。
+初期復元中にログ復元フェーズに入ると、 `br`は指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。
 
-初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントストレージに保存されます。pitr_id_maps **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。**
+初期リストア中のログリストアフェーズに入る前に、 `br`が`restored-ts`時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントストレージに保存されます。 **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。**
 
 > **Note:**
 >
diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md
index 16f3f7ac8cdbc..b72da16b24dab 100644
--- a/br/br-snapshot-guide.md
+++ b/br/br-snapshot-guide.md
@@ -134,7 +134,7 @@ tiup br restore table --pd "${PD_IP}:2379" \
 
 **テーブルフィルターを使用して複数のテーブルを復元します。**
 
-より複雑なフィルタルールを持つ複数のテーブルを復元するには、 `tiup br restore full`コマンド[テーブルフィルター](/table-filter.md)実行し、 `--filter`または`-f`を使用してテーブルを指定します。次の例では`db*.tbl*`フィルタルールに一致するテーブルをバックアップデータからターゲットクラスタに復元します。
+より複雑なフィルタルールを持つ複数のテーブルを復元するには、 `tiup br restore full`コマンドを実行し、 `--filter`または`-f`を使用して[テーブルフィルター](/table-filter.md)を指定します。次の例では`db*.tbl*`フィルタルールに一致するテーブルをバックアップデータからターゲットクラスタに復元します。
 
 ```shell
 tiup br restore full \
diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md
index 1609f9b4452fd..9b301979ce43a 100644
--- a/data-type-date-and-time.md
+++ b/data-type-date-and-time.md
@@ -175,7 +175,7 @@ CREATE TABLE t1 (
 
 ## 時間値の小数部分 {#decimal-part-of-time-value}
 
-`DATETIME`と`TIMESTAMP`値は、マイクロ秒単位の精度で最大 6 桁の小数部を持つことができます`DATETIME`型または`TIMESTAMP`型の列では、小数部は破棄されずに保存されます。小数部がある場合、値は「YYYY-MM-DD HH:MM:SS[.fraction]」の形式で表され、小数部の範囲は 000000 から 999999 です。小数部と残りの部分を区切るために小数点を使用する必要があります。
+`DATETIME`と`TIMESTAMP`値は、マイクロ秒単位の精度で最大 6 桁の小数部を持つことができます。 `DATETIME`型または`TIMESTAMP`型のいずれかの列では、小数部は破棄されずに保存されます。小数部がある場合、値は「YYYY-MM-DD HH:MM:SS[.fraction]」の形式で表され、小数部の範囲は 000000 から 999999 です。小数部と残りの部分を区切るために小数点を使用する必要があります。
 
 -   小数精度をサポートする列を定義するには`type_name(fsp)`使用します。3 `type_name` `TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、
 
diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md
index 607ae1243da4a..45945cd3dd50f 100644
--- a/develop/dev-guide-create-table.md
+++ b/develop/dev-guide-create-table.md
@@ -230,7 +230,7 @@ CREATE TABLE `bookshop`.`users` (
 >
 > このセクションで説明する手順は、クイック スタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAPを探索する](/explore-htap.md)参照してください。
 
-`ratings`アプリケーションを使用して`bookshop`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合`score`フィールドと`rated_at` `ratings` } フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。
+`bookshop`アプリケーションを使用して`ratings`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合、 `ratings`テーブル全体の`score`フィールドと`rated_at`フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。
 
 このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。
 
diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md
index 131fe19e62965..05cbae47c3424 100644
--- a/dm/dm-error-handling.md
+++ b/dm/dm-error-handling.md
@@ -146,7 +146,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機
 
 3.  アップストリーム内の対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。
 
-4.  リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid` ～ `true`指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。
+4.  リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid`を`true`に指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。
 
     例: エラーが発生した場合、 `binlog-name = "mysql-bin.004451"`と`binlog-pos = 2453`をそれぞれ`binlog-name = "mysql-bin.004452"`と`binlog-pos = 4`に更新し、 `binlog-gtid`を`f0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058`に更新します。
 
@@ -192,7 +192,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ
 
     デフォルトの`--statement-size`設定によると、ダンプ処理ユニットによって生成されるデフォルトのサイズ`Insert Statement`は約`1M`です。このデフォルト設定では、ロード処理ユニットはほとんどの場合、エラー`packet for query is too large. Try adjusting the 'max_allowed_packet' variable`報告しません。
 
-    データダンプ中に、以下のログが`WARN`出力されることがあります。この`WARN`はダンプ処理には影響しません。これは、幅の広いテーブルがダンプされたことを示しているだけです。
+    データダンプ中に、以下の`WARN`ログが出力されることがあります。この`WARN`ログはダンプ処理には影響しません。これは、幅の広いテーブルがダンプされたことを示しているだけです。
 
         Row bigger than statement_size for xxx
 
diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md
index 7959a96a1c879..6e255041e06be 100644
--- a/dm/maintain-dm-using-tiup.md
+++ b/dm/maintain-dm-using-tiup.md
@@ -161,7 +161,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262
 
 > **Note:**
 >
-> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)サポートします。
+> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)をサポートします。
 >
 > アップグレード前に、 `config export`使用してクラスターの設定ファイルをエクスポートできます。アップグレード後に以前のバージョンにダウングレードする必要がある場合は、まず以前のクラスターを再デプロイし、 `config import`使用して以前の設定ファイルをインポートできます。
 >
diff --git a/encryption-at-rest.md b/encryption-at-rest.md
index 3ecfc18555a5f..afe72771873e4 100644
--- a/encryption-at-rest.md
+++ b/encryption-at-rest.md
@@ -74,13 +74,13 @@ TiKVは現在、 CTRモードでAES128、AES192、AES256、またはSM4（バー
     data-encryption-method = "aes128-ctr"
     data-key-rotation-period = "168h" # 7 days
 
--   `data-encryption-method`暗号化アルゴリズムを指定します。指定可能な値は`"aes128-ctr"` 、 `"aes192-ctr"` 、 `"aes256-ctr"` 、 `"sm4-ctr"` （v6.3.0以降のバージョンのみ）、 `"plaintext"`です。デフォルト値は`"plaintext"`で、暗号化はデフォルトで無効になっています。
+-   `data-encryption-method`は、暗号化アルゴリズムを指定します。指定可能な値は`"aes128-ctr"` 、 `"aes192-ctr"` 、 `"aes256-ctr"` 、 `"sm4-ctr"` （v6.3.0以降のバージョンのみ）、 `"plaintext"`です。デフォルト値は`"plaintext"`で、暗号化はデフォルトで無効になっています。
 
     -   新しい TiKV クラスターまたは既存の TiKV クラスターの場合、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。
     -   暗号化を有効にした後に無効にするには、構成ファイルから`data-encryption-method`削除するか、その値を`"plaintext"`に設定して、TiKV を再起動します。
     -   暗号化アルゴリズムを変更するには、値`data-encryption-method`をサポートされている暗号化アルゴリズムに置き換え、TiKVを再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルが、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。
 
--   `data-key-rotation-period` 、TiKV がキーをローテーションする頻度を指定します。
+-   `data-key-rotation-period`は、TiKV がキーをローテーションする頻度を指定します。
 
 暗号化が有効になっている場合（つまり、 `data-encryption-method`値が`"plaintext"`ではない場合）、次のいずれかの方法でマスター キーを指定する必要があります。
 
@@ -305,7 +305,7 @@ AWS でキーを作成するには、TiKV のキーを作成する手順を参
 
 `data-encryption-method`に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、「sm4-ctr」（v6.4.0 以降のみ）、「plaintext」です。デフォルト値は「plaintext」で、暗号化は無効です。3 `data-key-rotation-period` 、 TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`削除するか、「plaintext」にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`サポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。
 
-暗号化が有効になっている場合（つまり、 `data-encryption-method` 「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。
+暗号化が有効になっている場合（つまり、 `data-encryption-method`が「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。
 
     [security.encryption.master-key]
     type = "kms"
diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md
index 072ff14e2432a..c8385f9c5d271 100644
--- a/faq/backup-and-restore-faq.md
+++ b/faq/backup-and-restore-faq.md
@@ -176,9 +176,9 @@ BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-cre
 
 TiKVがバックアップディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKVに書き込み権限があるかどうかを確認してください。データを復元するには、TiKVに読み取り権限があるかどうかを確認してください。
 
-バックアップ操作中、ストレージメディアがローカルディスクまたはネットワークファイルシステム（NFS）の場合、 `br`起動するユーザーとTiKVを起動するユーザーが一致していることを確認してください（ `br`とTiKVが異なるマシン上にある場合は、ユーザーのUIDが一致している必要があります）。一致していない場合、 `Permission denied`問題が発生する可能性があります。
+バックアップ操作中、ストレージメディアがローカルディスクまたはネットワークファイルシステム（NFS）の場合、 `br`を起動するユーザーとTiKVを起動するユーザーが一致していることを確認してください（ `br`とTiKVが異なるマシン上にある場合は、ユーザーのUIDが一致している必要があります）。一致していない場合、 `Permission denied`問題が発生する可能性があります。
 
-バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、ディスク権限が原因で`br` `root`ユーザーとして実行すると失敗する可能性があります。
+バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、ディスク権限が原因で`br`を`root`ユーザーとして実行すると失敗する可能性があります。
 
 > **Note:**
 >
diff --git a/foreign-key.md b/foreign-key.md
index edde854c3bd2c..4fdb1ba07705b 100644
--- a/foreign-key.md
+++ b/foreign-key.md
@@ -66,7 +66,7 @@ ReferenceOption
 `UPDATE`または`DELETE`操作が親テーブルの外部キー値に影響を与える場合、子テーブルの対応する外部キー値は、外部キー定義の`ON UPDATE`または`ON DELETE`句で定義された参照操作によって決定されます。参照操作には、次のものが含まれます。
 
 -   `CASCADE` : `UPDATE`または`DELETE`操作が親テーブルに影響を与える場合、子テーブルの対応する行を自動的に更新または削除します。カスケード操作は深さ優先で実行されます。
--   `SET NULL` : `NULL`操作が親テーブルに影響を与える場合、子テーブルの対応する外部キー列を自動的に {{B `UPDATE` `DELETE`に設定します。
+-   `SET NULL` : `UPDATE`または`DELETE`操作が親テーブルに影響を与える場合、子テーブルの対応する外部キー列を自動的に`NULL`に設定します。
 -   `RESTRICT` : 子テーブルに一致する行が含まれている場合、 `UPDATE`または`DELETE`操作を拒否します。
 -   `NO ACTION` : `RESTRICT`と同じです。
 -   `SET DEFAULT` : `RESTRICT`と同じです。
diff --git a/functions-and-operators/json-functions/json-functions-validate.md b/functions-and-operators/json-functions/json-functions-validate.md
index d2c7ef06ae626..32641e2bd019e 100644
--- a/functions-and-operators/json-functions/json-functions-validate.md
+++ b/functions-and-operators/json-functions/json-functions-validate.md
@@ -139,7 +139,7 @@ SELECT JSON_SCHEMA_VALID('{"required": ["fruits","vegetables","grains"]}',@j);
     +------------------------------------------------------------------------+
     1 row in set (0.00 sec)
 
-上記の出力から、 `fruits` 、 `vegetables` 、 `grains` }}属性の存在検証が、 `grains`存在しないため失敗していることがわかります。
+上記の出力から、 `fruits` 、 `vegetables` 、 `grains`属性の存在検証が、 `grains`が存在しないため失敗していることがわかります。
 
 `fruits`が配列であることを検証します。
 
diff --git a/functions-and-operators/window-functions.md b/functions-and-operators/window-functions.md
index 9e2e1bda5e9b2..99241f9dc3cba 100644
--- a/functions-and-operators/window-functions.md
+++ b/functions-and-operators/window-functions.md
@@ -99,7 +99,7 @@ FROM (
 
 ## `FIRST_VALUE()` {#first-value}
 
-`FIRST_VALUE(expr)`ウィンドウ内の最初の値を返します。
+`FIRST_VALUE(expr)`は、ウィンドウ内の最初の値を返します。
 
 次の例では、 2 つの異なるウィンドウ定義を使用しています。
 
@@ -136,7 +136,7 @@ ORDER BY
 
 ## `LAG()` {#lag}
 
-`LAG(expr [, num [, default]])`関数は、現在行の`num`行前にある行の値`expr`を返します。そのような行が存在しない場合は、 `default`が返されます。デフォルトでは、 `num`は`1`は`default` `NULL`扱われます。
+`LAG(expr [, num [, default]])`関数は、現在行の`num`行前にある行の値`expr`を返します。そのような行が存在しない場合は、 `default`が返されます。デフォルトでは、指定されていない場合、 `num`は`1` 、 `default`は`NULL`として扱われます。
 
 次の例では、 `num`指定されていないため、 `LAG(n)`前の行の`n`の値を返します。7が`n`の場合、前の行は存在せず、 `default`指定されていないため、 `LAG(1)`は`NULL`返します。
 
diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md
index ad834af095bcb..74e864e4fffb3 100644
--- a/migrate-large-mysql-shards-to-tidb.md
+++ b/migrate-large-mysql-shards-to-tidb.md
@@ -11,7 +11,7 @@ summary: DumplingとTiDB Lightningを使用して、MySQLからTiDBへ大規模
 
 MySQL シャードのデータ サイズが 1 TiB 未満の場合は、[小規模データセットのMySQLシャードをTiDBに移行およびマージする](/migrate-small-mysql-shards-to-tidb.md)で説明されている手順に従うことができます。この手順では、完全移行と増分移行の両方がサポートされており、手順がより簡単です。
 
-このドキュメントの例では、 `my_db1`と`my_db2` 2 つのデータベースがあることを前提としています。Dumplingを使用して`table1`から 2 つのテーブル {{ `table2`と`my_db1` `table3`から 2 つのテーブル`table4`と`my_db2`をそれぞれエクスポートします。その後、 TiDB Lightning を使用して、エクスポートされた 4 つのテーブルをターゲット TiDB の`mydb` `table5`にインポートしてマージします。
+このドキュメントの例では、 `my_db1`と`my_db2`の 2 つのデータベースがあることを前提としています。Dumplingを使用して`my_db1`から 2 つのテーブル`table1`と`table2`を、 `my_db2`から 2 つのテーブル`table3`と`table4`をそれぞれエクスポートします。その後、 TiDB Lightning を使用して、エクスポートされた 4 つのテーブルをターゲット TiDB の`mydb`にある同じ`table5`にインポートしてマージします。
 
 このドキュメントでは、以下の手順に従ってデータを移行する方法を説明します。
 
@@ -52,7 +52,7 @@ CREATE TABLE `table1` (
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1
 ```
 
-これら 4 つのテーブルでは、 `id`列が主キーです。この列はAUTO_INCREMENTであるため、異なるシャーディング テーブルで重複する`id`範囲が生成され、移行中にターゲット テーブルで主キーの競合が発生します。一方、 `sid`列はシャーディング キーであり、インデックスがグローバルに一意であることを保証します。したがって、ターゲット`id`の { `table5` -E}} 列の一意制約を削除することで、データ マージの競合を回避できます。
+これら 4 つのテーブルでは、 `id`列が主キーです。この列はAUTO_INCREMENTであるため、異なるシャーディング テーブルで重複する`id`範囲が生成され、移行中にターゲット テーブルで主キーの競合が発生します。一方、 `sid`列はシャーディング キーであり、インデックスがグローバルに一意であることを保証します。したがって、ターゲットの`table5`における`id`列の一意制約を削除することで、データ マージの競合を回避できます。
 
 ```sql
 CREATE TABLE `table5` (
diff --git a/optimizer-hints.md b/optimizer-hints.md
index 26873e4e55325..8de0a6570de4c 100644
--- a/optimizer-hints.md
+++ b/optimizer-hints.md
@@ -655,7 +655,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ *
 
 > **Note:**
 >
-> -   ビューでグローバルヒントを使用するには、対応するヒントをビューに`QB_NAME`定義する必要があります。そうしないと、グローバルヒントは有効になりません。
+> -   ビューでグローバルヒントを使用するには、対応する`QB_NAME`ヒントをビューに定義する必要があります。そうしないと、グローバルヒントは有効になりません。
 >
 > -   ヒントを使用してビュー内の複数のテーブル名を指定する場合、同じヒントに表示されるテーブル名が同じビューの同じクエリ ブロック内にあることを確認する必要があります。
 >
@@ -844,7 +844,7 @@ SELECT /*+ NTH_PLAN(3) */ count(*) from t where a > 5;
 
 ### RESOURCE_GROUP(リソースグループ名) {#resource-group-resource-group-name}
 
-`RESOURCE_GROUP(resource_group_name)`は[リソース管理](/tidb-resource-control-ru-groups.md)代わりにリソースを分離するために使用されます。このヒントは、指定されたリソースグループを使用して現在のステートメントを一時的に実行します。指定されたリソースグループが存在しない場合、このヒントは無視されます。
+`RESOURCE_GROUP(resource_group_name)`は、[リソース管理](/tidb-resource-control-ru-groups.md)でリソースを分離するために使用されます。このヒントは、指定されたリソースグループを使用して現在のステートメントを一時的に実行します。指定されたリソースグループが存在しない場合、このヒントは無視されます。
 
 例：
 
diff --git a/partition-pruning.md b/partition-pruning.md
index aea8230e7e54a..a9a1934965582 100644
--- a/partition-pruning.md
+++ b/partition-pruning.md
@@ -72,7 +72,7 @@ explain select * from t where x = 1;
 
 ##### シナリオ1 {#scenario-one}
 
-クエリ結果`between` 1つの`>` `in` ）のみに該当するという条件を確認できない場合は、パーティションプルーニング最適化`<=`使用できません。 `<` `>=`
+クエリ結果が1つのパーティションのみに該当するという条件（ `in` 、 `between` 、 `>` 、 `<` 、 `>=` 、 `<=`など）を確認できない場合は、パーティションプルーニング最適化を使用できません。例:
 
 ```sql
 create table t (x int) partition by hash(x) partitions 4;
diff --git a/partitioned-table.md b/partitioned-table.md
index 9d349cc872576..d63dbdc715865 100644
--- a/partitioned-table.md
+++ b/partitioned-table.md
@@ -673,7 +673,7 @@ PARTITIONS 2;
 
 -   MySQL の線形ハッシュパーティションの`CREATE`ステートメントの場合、TiDB は非線形ハッシュパーティションテーブルを作成します (TiDB には線形ハッシュパーティションテーブルはありません)。パーティション数が 2 のべき乗の場合、TiDB ハッシュパーティションテーブルの行は MySQL の線形ハッシュパーティションテーブルと同じように分散されます。それ以外の場合、TiDB でのこれらの行の分散は MySQL とは異なります。これは、非線形パーティションテーブルは単純な「パーティション数の剰余」を使用するのに対し、線形パーティションテーブルは「次の 2 のべき乗の剰余」を使用し、パーティション数と次の 2 のべき乗の間の値を折り返す」ためです。詳細については、 [#38450](https://github.com/pingcap/tidb/issues/38450)を参照してください。
 
--   MySQL の線形ハッシュパーティションのその他のすべてのステートメントについては、パーティション数が 2 のべき乗でない場合、行の分散方法が異なることを除いて、TiDB では MySQL と同じように動作します。このため、次のような結果になります[パーティション選択](#partition-selection)、 `TRUNCATE PARTITION` 、および`EXCHANGE PARTITION` 。
+-   MySQL の線形ハッシュパーティションのその他のすべてのステートメントについては、パーティション数が 2 のべき乗でない場合、行の分散方法が異なることを除いて、TiDB では MySQL と同じように動作します。この違いにより、 [パーティション選択](#partition-selection)、 `TRUNCATE PARTITION` 、および`EXCHANGE PARTITION`の結果は MySQL とは異なります。
 
 ### TiDBが線形キーパーティションを処理する方法 {#how-tidb-handles-linear-key-partitions}
 
@@ -1340,7 +1340,7 @@ SELECT store_id, COUNT(department_id) AS c
     +---|----------+
     2 rows in set (0.00 sec)
 
-パーティション選択は、範囲パーティショニングやハッシュパーティショニングを含む、すべてのタイプのテーブルパーティショニングでサポートされています。ハッシュパーティションの場合、パーティション名が指定されていないときは、{{B `p1` `p0` 、 `p2` 、...、または`pN-1`がパーティション名として自動的に使用されます。
+パーティション選択は、範囲パーティショニングやハッシュパーティショニングを含む、すべてのタイプのテーブルパーティショニングでサポートされています。ハッシュパーティションの場合、パーティション名が指定されていないときは、 `p0` 、 `p1` 、 `p2` 、...、または`pN-1`がパーティション名として自動的に使用されます。
 
 `SELECT`内の`INSERT ... SELECT`もパーティション選択を使用できます。
 
diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md
index 01185bd4d91c9..4289619500d8e 100644
--- a/performance-tuning-practices.md
+++ b/performance-tuning-practices.md
@@ -191,7 +191,7 @@ TiDB の平均 CPU 使用率は 874% から 936% に増加します。
 
 ### アプリケーション構成 {#application-configuration}
 
-アプリケーション構成はシナリオ 3 と同じままです。アプリケーションが`StmtClose`トリガーしてもキャッシュにヒットしない問題を解決するために、次のパラメータが構成されています。
+アプリケーション構成はシナリオ 3 と同じままです。アプリケーションが`StmtClose`をトリガーしてもキャッシュにヒットしない問題を解決するために、次のパラメータが構成されています。
 
 -   TiDB グローバル変数`set global tidb_ignore_prepared_cache_close_stmt=on;`を設定します (TiDB v6.0.0 以降に導入、デフォルトは`off` )。
 -   プラン キャッシュ機能を有効にするには、TiDB 構成項目`prepared-plan-cache: {enabled: true}`を設定します。
diff --git a/privilege-management.md b/privilege-management.md
index 523ea8aa0c827..1a84050f07a6f 100644
--- a/privilege-management.md
+++ b/privilege-management.md
@@ -391,7 +391,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'";
 
 `SHOW IMPORT JOB`は、他のユーザーに属する接続を表示するために`SUPER`権限を必要とします。権限がない場合は、現在のユーザーが作成したジョブのみが表示されます。
 
-`SHOW STATS_LOCKED`は`SELECT` `mysql.stats_table_locked` }} テーブルに対する権限を必要とします。
+`SHOW STATS_LOCKED`は`mysql.stats_table_locked`テーブルに対する`SELECT`権限を必要とします。
 
 ### ロール/ユーザーの作成 {#create-role-user}
 
@@ -489,7 +489,7 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1;
 
 > **Note:**
 >
-> `GRANT` 、 `CREATE USER` }}、 `DROP USER` `FLUSH PRIVILEGES`が実行されるまで予期しない動作が発生する可能性があります。
+> 権限テーブルの更新には、 `GRANT` 、 `CREATE USER` 、 `DROP USER`などの提供されている構文のみを使用することをお勧めします。基盤となる権限テーブルを直接編集しても権限キャッシュは自動的に更新されないため、 `FLUSH PRIVILEGES`が実行されるまで予期しない動作が発生する可能性があります。
 
 ### 接続確認 {#connection-verification}
 
diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md
index 7db1dd708492c..595c69af78495 100644
--- a/releases/release-2.1-beta.md
+++ b/releases/release-2.1-beta.md
@@ -75,7 +75,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ
 
 -   Rustをバージョン`nightly-2018-06-14`にアップグレードする
 -   `Raft PreVote`有効にすると、ネットワーク分離後にネットワークが回復したときに生成されるリーダーの再選出を回避します。
--   RocksDBの各レイヤーのファイル数と関連情報`ingest`表示するメトリックを追加します。
+-   RocksDBの各レイヤーのファイル数と`ingest`関連情報を表示するメトリックを追加します。
 -   GC が機能しているときにバージョンが多すぎると`key`印刷する
 -   `static metric`使用してマルチラベルメトリックのパフォーマンスを最適化します（YCSB `raw get` 3％向上します）
 -   複数のモジュールから`box`削除し、パターンを使用して動作パフォーマンスを改善します（YCSB `raw get` 3％向上します）
diff --git a/releases/release-3.0.11.md b/releases/release-3.0.11.md
index 18cf5b772bce1..169e804551e6a 100644
--- a/releases/release-3.0.11.md
+++ b/releases/release-3.0.11.md
@@ -42,8 +42,8 @@ TiDB Ansible バージョン: 3.0.11
     -   `Sort Merge Join`と`ORDER BY DESC`同時に含まれるSQL文によって発生する誤った結果を修正する[＃14664](https://github.com/pingcap/tidb/pull/14664)
     -   サポートされていない式を使用してパーティションテーブルを作成する際にTiDBサーバーがpanicを修正しました。このpanicを修正すると、エラー情報`This partition function is not allowed`返されます[＃14769](https://github.com/pingcap/tidb/pull/14769)
     -   `Union` を含むサブクエリで`select max() from subquery`文を実行したときに発生した誤った結果を修正しました [＃14944](https://github.com/pingcap/tidb/pull/14944)
-    -   実行バインディングを削除する`DROP BINDING`実行した後に`SHOW BINDINGS`ステートメントを実行するとエラーメッセージが返される問題を修正しました [＃14865](https://github.com/pingcap/tidb/pull/14865)
-    -   MySQLプロトコルではクエリのエイリアスの最大長が256文字であるが、TiDBはこのプロトコルに従ってクエリ結果に[別名を切る](https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html)出力しないため、接続が切断される問題を修正しました。 [＃14940](https://github.com/pingcap/tidb/pull/14940)
+    -   実行バインディングを削除する`DROP BINDING`を実行した後に`SHOW BINDINGS`ステートメントを実行するとエラーメッセージが返される問題を修正しました [＃14865](https://github.com/pingcap/tidb/pull/14865)
+    -   MySQLプロトコルではクエリのエイリアスの最大長が256文字であるにもかかわらず、TiDBがこのプロトコルに従ってクエリ結果の[エイリアスを切り詰め](https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html)ないため、接続が切断される問題を修正しました。 [＃14940](https://github.com/pingcap/tidb/pull/14940)
     -   `DIV`で文字列型を使用した際に発生する可能性のある誤ったクエリ結果を修正しました。例えば、 `select 1 / '2007' div 1`文正しく実行できるようになりました。 [＃14098](https://github.com/pingcap/tidb/pull/14098)
 
 -   TiKV
diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md
index 24f8472d80384..0ee976bee783b 100644
--- a/releases/release-5.2.4.md
+++ b/releases/release-5.2.4.md
@@ -72,7 +72,7 @@ TiDBバージョン：5.2.4
     -   innerWorkerのpanicによって発生したインデックス結合の誤った結果を修正 [#31494](https://github.com/pingcap/tidb/issues/31494)
     -   `INSERT ... SELECT ... ON DUPLICATE KEY UPDATE`ステートメントを実行するとpanicが発生する問題を修正しました [#28078](https://github.com/pingcap/tidb/issues/28078)
     -   `Order By`の最適化による誤ったクエリ結果を修正 [#30271](https://github.com/pingcap/tidb/issues/30271)
-    -   `JOIN` `ENUM` -E}}を実行した際に発生する可能性のある誤った結果を修正します [#27831](https://github.com/pingcap/tidb/issues/27831)
+    -   `ENUM`型の列で`JOIN`を実行した際に発生する可能性のある誤った結果を修正します [#27831](https://github.com/pingcap/tidb/issues/27831)
     -   `CASE WHEN`データ型で`ENUM`関数を使用した際に発生panicを修正しました [#29357](https://github.com/pingcap/tidb/issues/29357)
     -   ベクトル化された式における`microsecond`関数の誤った結果を修正 [#29244](https://github.com/pingcap/tidb/issues/29244)
     -   ウィンドウ関数がエラーを報告する代わりにTiDBをpanicにする問題を修正しました [#30326](https://github.com/pingcap/tidb/issues/30326)
diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md
index fc841b260f7f6..99441b6eed1ee 100644
--- a/releases/release-7.3.0.md
+++ b/releases/release-7.3.0.md
@@ -121,7 +121,7 @@ TiDB バージョン: 7.3.0
 
 -   TiDB
 
-    -   MPP はTiFlashエンジンが提供する分散コンピューティング フレームワークであり、ノード間でのデータ交換を可能にし、高性能かつ高スループットの SQL アルゴリズムを提供します。他のプロトコルと比較して、MPP プロトコルはより成熟しており、より優れたタスクおよびリソース管理を提供できます。v7.3.0 以降、TiDB が計算タスクをTiFlashにプッシュする場合、オプティマイザはデフォルトで MPP プロトコルを使用した実行プランのみを生成します。tidb_allow_mpp が`OFF`に設定されている場合、TiDB をアップグレードした後にクエリでエラーが発生する可能性があります。 [`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50)前に`tidb_allow_mpp`の値を確認し、 `ON`に設定することをお勧めします。コスト見積もりに基づいて実行プランを生成するために、オプティマイザがCop、BatchCop、およびMPPプロトコルのいずれかを選択する必要がある場合は、 [`tidb_allow_tiflash_cop`](/system-variables.md#tidb_allow_tiflash_cop-new-in-v730)変数を`ON`に設定できます。
+    -   MPP はTiFlashエンジンが提供する分散コンピューティング フレームワークであり、ノード間でのデータ交換を可能にし、高性能かつ高スループットの SQL アルゴリズムを提供します。他のプロトコルと比較して、MPP プロトコルはより成熟しており、より優れたタスクおよびリソース管理を提供できます。v7.3.0 以降、TiDB が計算タスクをTiFlashにプッシュする場合、オプティマイザはデフォルトで MPP プロトコルを使用した実行プランのみを生成します。[`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50)が`OFF`に設定されている場合、TiDB をアップグレードした後にクエリでエラーが発生する可能性があります。アップグレードの前に`tidb_allow_mpp`の値を確認し、 `ON`に設定することをお勧めします。コスト見積もりに基づいて実行プランを生成するために、オプティマイザがCop、BatchCop、およびMPPプロトコルのいずれかを選択する必要がある場合は、 [`tidb_allow_tiflash_cop`](/system-variables.md#tidb_allow_tiflash_cop-new-in-v730)変数を`ON`に設定できます。
 
 -   Backup & Restore (BR)
 
diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md
index c6fa0b295e015..3193695a9ec11 100644
--- a/releases/release-8.2.0.md
+++ b/releases/release-8.2.0.md
@@ -293,7 +293,7 @@ TiDB バージョン: 8.2.0
     -   `CURRENT_DATE()`を列のデフォルト値として使用するとクエリ結果が正しくない問題を修正 [#53746](https://github.com/pingcap/tidb/issues/53746) @[tangenta](https://github.com/tangenta)
     -   `ALTER DATABASE ... SET TIFLASH REPLICA`ステートメントがTiFlashレプリカを`SEQUENCE`テーブルに誤って追加する問題を修正しました [#51990](https://github.com/pingcap/tidb/issues/51990) @[jiyfhust](https://github.com/jiyfhust)
     -   `REFERENCED_TABLE_SCHEMA`テーブルの`INFORMATION_SCHEMA.KEY_COLUMN_USAGE`フィールドが正しくない問題を修正します [#52350](https://github.com/pingcap/tidb/issues/52350) @[wd0517](https://github.com/wd0517)
-    -   単一のステートメントで複数の行を挿入すると、{{B `AUTO_ID_CACHE=1` `AUTO_INCREMENT`列が不連続になる問題を修正しました。 [#52465](https://github.com/pingcap/tidb/issues/52465) @[tiancaiamao](https://github.com/tiancaiamao)
+    -   `AUTO_ID_CACHE=1`の場合に、単一のステートメントで複数の行を挿入すると`AUTO_INCREMENT`列が不連続になる問題を修正しました。 [#52465](https://github.com/pingcap/tidb/issues/52465) @[tiancaiamao](https://github.com/tiancaiamao)
     -   非推奨警告のフォーマットを修正 [#52515](https://github.com/pingcap/tidb/issues/52515) @[dveeden](https://github.com/dveeden)
     -   `TRACE`で`copr.buildCopTasks`コマンドが欠落している問題を修正 [#53085](https://github.com/pingcap/tidb/issues/53085) @[time-and-fate](https://github.com/time-and-fate)
     -   `memory_quota`ヒントがサブクエリで機能しない可能性がある問題を修正しました [#53834](https://github.com/pingcap/tidb/issues/53834) @[qw4990](https://github.com/qw4990)
diff --git a/sql-statements/sql-statement-create-table.md b/sql-statements/sql-statement-create-table.md
index 6436cb56e8be2..cdfaf1992279c 100644
--- a/sql-statements/sql-statement-create-table.md
+++ b/sql-statements/sql-statement-create-table.md
@@ -159,7 +159,7 @@ NextValueForSequence ::=
 |   "NEXTVAL" '(' TableName ')'
 ```
 
-以下の*テーブルオプション*がサポートされています。 `AVG_ROW_LENGTH` 、 `CHECKSUM` 、 `COMPRESSION` 、 `CONNECTION` 、 `DELAY_KEY_WRITE` 、 {{B `ENGINE` 、 `KEY_BLOCK_SIZE` 、 `MAX_ROWS` 、 `MIN_ROWS`および`STATS_PERSISTENT` `ROW_FORMAT`のその他のオプションは解析されますが無視されます。
+以下の*テーブルオプション*がサポートされています。 `AVG_ROW_LENGTH` 、 `CHECKSUM` 、 `COMPRESSION` 、 `CONNECTION` 、 `DELAY_KEY_WRITE` 、 `ENGINE` 、 `KEY_BLOCK_SIZE` 、 `MAX_ROWS` 、 `MIN_ROWS` 、 `ROW_FORMAT`および`STATS_PERSISTENT`などのその他のオプションは解析されますが無視されます。
 
 | オプション                                        | 説明                                                                                                                                                                          | 例                                   |
 | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
diff --git a/statement-summary-tables.md b/statement-summary-tables.md
index 4e9dc0159d1d3..79f01141f62ba 100644
--- a/statement-summary-tables.md
+++ b/statement-summary-tables.md
@@ -137,7 +137,7 @@ select * from employee where id in (...) and salary between ? and ?;
     > **Note:**
     >
     > -   SQLダイジェストが削除されると、関連するすべての時間範囲のサマリーデータが`statements_summary`テーブルと`statements_summary_history`テーブルの両方から削除されます。その結果、特定の時間範囲内のSQLダイジェストの数が制限を超えない場合でも、 `statements_summary_history`テーブルのSQLダイジェストの数が実際のSQLダイジェストの数よりも少なくなる可能性があります。このような状況が発生し、パフォーマンスに影響する場合は、 `tidb_stmt_summary_max_stmt_count`の値を増やすことをお勧めします。
-    > -   TiDB Self-Managed の場合、 [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary)が有効になっていると、 `statements_summary_history`テーブルのデータがディスクに永続化されます。この場合、 `tidb_stmt_summary_max_stmt_count` `statements_summary`テーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、 `statements_summary` -E}} を超えると、TiDB は`tidb_stmt_summary_max_stmt_count`のみを削除します。
+    > -   TiDB Self-Managed の場合、 [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary)が有効になっていると、 `statements_summary_history`テーブルのデータがディスクに永続化されます。この場合、 `tidb_stmt_summary_max_stmt_count`は、 `statements_summary`テーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、TiDB は`tidb_stmt_summary_max_stmt_count`を超えると`statements_summary`テーブルから最も使用頻度の低い SQL ダイジェストのみを削除します。
 
 -   `tidb_stmt_summary_max_sql_length` : `DIGEST_TEXT`と`QUERY_SAMPLE_TEXT`の最長表示長を指定します。デフォルト値は`4096`です。
 
@@ -431,7 +431,7 @@ TiKVコプロセッサータスクに関連するフィールド：
 -   `SUM_BACKOFF_TIMES` : このカテゴリの SQL ステートメントで再試行が必要なエラーが発生した場合の再試行回数の合計。
 -   `BACKOFF_TYPES` : 再試行が必要なすべてのエラーの種類と、各種類の再試行回数。フィールドの形式は`type:number`です。エラーの種類が複数ある場合は、それぞれをカンマで区切ります。例: `txnLock:2,pdRPC:1` 。
 -   `AVG_AFFECTED_ROWS` : 影響を受けた行の平均数。
--   `PREV_SAMPLE_TEXT` : 現在の SQL ステートメントが`COMMIT`の場合、 `PREV_SAMPLE_TEXT`は`COMMIT`の前のステートメントです。この場合、SQL ステートメントはダイジェストと`prev_sample_text`でグループ化されます。つまり、 `COMMIT`が異なる`prev_sample_text`ステートメントは、異なる行にグループ化されます。現在の SQL ステートメントが`COMMIT`でない場合、 `PREV_SAMPLE_TEXT`フィールドは空の文字列になります。
+-   `PREV_SAMPLE_TEXT` : 現在の SQL ステートメントが`COMMIT`の場合、 `PREV_SAMPLE_TEXT`は`COMMIT`の前のステートメントです。この場合、SQL ステートメントはダイジェストと`prev_sample_text`でグループ化されます。つまり、 `prev_sample_text`が異なる`COMMIT`ステートメントは、異なる行にグループ化されます。現在の SQL ステートメントが`COMMIT`でない場合、 `PREV_SAMPLE_TEXT`フィールドは空の文字列になります。
 
 リソース制御に関連する分野：
 
diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md
index b2b90e7344b2c..1d7da607f02b8 100644
--- a/sync-diff-inspector/sync-diff-inspector-overview.md
+++ b/sync-diff-inspector/sync-diff-inspector-overview.md
@@ -193,7 +193,7 @@ collation = ""
 ./sync_diff_inspector --config=./config.toml
 ```
 
-このコマンドは`summary.txt`の`output-dir`にチェック レポート`config.toml`とログ`sync_diff.log`を出力します。また、 `output-dir` }} には、 `config. toml`ファイルのハッシュ値で命名されたフォルダも生成されます。このフォルダには、ブレークポイントのチェックポイント ノード情報と、データに不整合が生じた場合に生成される SQL ファイルが含まれます。
+このコマンドは`summary.txt`の`output-dir`にチェック レポート`config.toml`とログ`sync_diff.log`を出力します。また、 `output-dir`には、 `config. toml`ファイルのハッシュ値で命名されたフォルダも生成されます。このフォルダには、ブレークポイントのチェックポイント ノード情報と、データに不整合が生じた場合に生成される SQL ファイルが含まれます。
 
 ### 進捗状況 {#progress-information}
 
diff --git a/system-variables.md b/system-variables.md
index 944803d1e43e9..cbbfaff5c0f66 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -58,7 +58,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10;
 -   ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ
 -   型: Boolean
 -   デフォルト値: `OFF`
--   `AUTO_RANDOM`ステートメントで、 `INSERT` -E}} 属性を持つ列の値を明示的に指定することを許可するかどうかを決定します。
+-   `INSERT`ステートメントで、 `AUTO_RANDOM`属性を持つ列の値を明示的に指定することを許可するかどうかを決定します。
 
 ### authentication_ldap_sasl_auth_method_name <span class="version-mark">v7.1.0で追加</span> {#authentication-ldap-sasl-auth-method-name-new-in-v710}
 
@@ -1781,7 +1781,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー
 -   型: Enumeration
 -   デフォルト値: `PRIORITY_LOW`
 -   値のオプション: `PRIORITY_LOW` 、 `PRIORITY_NORMAL` 、 `PRIORITY_HIGH`
--   この変数は`ADD INDEX`フェーズで`re-organize` } 操作を実行する優先順位を設定するために使用されます。
+-   この変数は`re-organize`フェーズで`ADD INDEX`操作を実行する優先順位を設定するために使用されます。
 -   この変数の値を`PRIORITY_LOW` 、 `PRIORITY_NORMAL`または`PRIORITY_HIGH`に設定できます。
 
 ### tidb_ddl_reorg_max_write_speed は<span class="version-mark">、v6.5.12、v7.5.5、v8.5.0 で新たに追加されました。</span> {#tidb-ddl-reorg-max-write-speed-span-class-version-mark-new-in-v6-5-12-v7-5-5-and-v8-5-0-span}
@@ -4664,7 +4664,7 @@ mysql> desc select count(distinct a) from test.t;
 
 -   範囲: `[-1, 1]`
 
--   この変数は、SQL ステートメントに`ORDER BY`および`ORDER BY` -E}} 句がある場合に、SQL ステートメント`LIMIT`に一致するインデックスの推定行数を制御しますが、一部のフィルタ条件はカバーしません。
+-   この変数は、SQL ステートメントに`ORDER BY`および`LIMIT`句がある場合に、SQL ステートメント`ORDER BY`に一致するインデックスの推定行数を制御しますが、一部のフィルタ条件はカバーしません。
 
 -   これは、システム変数[tidb_opt_ordering_index_selectivity_threshold](#tidb_opt_ordering_index_selectivity_threshold-new-in-v700)と同じクエリパターンに対応します。
 
@@ -5691,7 +5691,7 @@ SHOW WARNINGS;
     -   `tidb_restricted_read_only`を`OFF`に設定しても、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)は変更されません。
     -   `tidb_restricted_read_only`が`ON`の場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531) `OFF`に設定することはできません。
 -   TiDB の DBaaS プロバイダーの場合、TiDB クラスタが別のデータベースのダウンストリーム データベースである場合、TiDB クラスタを読み取り専用にするには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にした上で`tidb_restricted_read_only`を使用する必要がある場合があります。これにより、顧客が[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)を使用してクラスタを書き込み可能にすることができなくなります。これを実現するには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にし、 `SYSTEM_VARIABLES_ADMIN`および`RESTRICTED_VARIABLES_ADMIN`権限を持つ管理者ユーザーを使用して`tidb_restricted_read_only`を制御し、データベース ユーザーには、 `SUPER`権限を持つルート ユーザーを使用して[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを制御させる必要があります。
--   この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` -E}} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。
+-   この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` 、 `SHOW` など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。
 -   この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。
 -   TiDB は、SQL ステートメントの実行前に読み取り専用フラグを確認します。v6.2.0 以降では、SQL ステートメントのコミット前にもフラグがチェックされます。これにより、サーバーが読み取り専用モードになった後に、長時間実行される[自動コミット](/transaction-overview.md#autocommit)ステートメントがデータを変更するケースを防ぐことができます。
 -   この変数が有効になっている場合、TiDB はコミットされていないトランザクションを次のように処理します。
@@ -6365,7 +6365,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec)
 -   デフォルト値: `OFF`
 -   `tidb_super_read_only` MySQL 変数`super_read_only`の代替として実装されることを目的としています。ただし、TiDB は分散データベースであるため、 `tidb_super_read_only`実行直後にデータベースを読み取り専用にするのではなく、最終的に読み取り専用にします。
 -   `SUPER`または`SYSTEM_VARIABLES_ADMIN`の権限を持つユーザーは、この変数を変更できます。
--   この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` }} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。
+-   この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` 、 `SHOW` など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。
 -   この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。
 -   TiDB は、SQL ステートメントの実行前に読み取り専用フラグを確認します。v6.2.0 以降では、SQL ステートメントのコミット前にもフラグがチェックされます。これにより、サーバーが読み取り専用モードになった後に、長時間実行される[自動コミット](/transaction-overview.md#autocommit)ステートメントがデータを変更するケースを防ぐことができます。
 -   この変数が有効になっている場合、TiDB はコミットされていないトランザクションを次のように処理します。
diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md
index 8448ed66da974..40db4e7b52d0b 100644
--- a/ticdc/ticdc-open-api-v2.md
+++ b/ticdc/ticdc-open-api-v2.md
@@ -668,7 +668,7 @@ changefeed 設定を変更するには、 `pause the replication task -> modify
 | `sink_uri`       | `STRING`型。レプリケーションタスクのダウンストリームアドレス。（オプション）  |
 | `replica_config` | シンクの設定パラメータ。すべて指定する必要があります。（オプション）          |
 
-上記のパラメータの意味はセクション[レプリケーションタスクを作成する](#create-a-replication-task)と同じです。詳細については、セクション1を参照してください。
+上記のパラメータの意味はセクション[レプリケーションタスクを作成する](#create-a-replication-task)と同じです。詳細については、当該セクションを参照してください。
 
 ### 例 {#example}
 
@@ -762,7 +762,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds?state=normal
 curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1
 ```
 
-JSONレスポンスボディの意味はセクション[レプリケーションタスクを作成する](#create-a-replication-task)と同じです。詳細はセクション1を参照してください。
+JSONレスポンスボディの意味はセクション[レプリケーションタスクを作成する](#create-a-replication-task)と同じです。詳細は当該セクションを参照してください。
 
 ## 特定のレプリケーションタスクが完了したかどうかを照会する {#query-whether-a-specific-replication-task-is-completed}
 
diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md
index 418637ca6df9e..2751f718e5aff 100644
--- a/tidb-cloud/changefeed-sink-to-mysql.md
+++ b/tidb-cloud/changefeed-sink-to-mysql.md
@@ -165,7 +165,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること
 
 8.  **「レプリケーション開始位置」**で、MySQLシンクの開始位置を設定します。
 
-    -   Dumplingを使用して[既存のデータをロードしました](#load-existing-data-optional)がある場合は、 **[特定の TSO からレプリケーションを開始する]**を選択し、 Dumpling のエクスポートされたメタデータ ファイルから取得した TSO を入力します。
+    -   Dumplingを使用して[既存のデータをロードした](#load-existing-data-optional)場合は、 **[特定の TSO からレプリケーションを開始する]**を選択し、 Dumpling のエクスポートされたメタデータ ファイルから取得した TSO を入力します。
     -   アップストリームの TiDB にデータがない場合は、 **「今すぐレプリケーションを開始する」**を選択してください。
     -   それ以外の場合は、 **「特定の時間からレプリケーションを開始する」**を選択して、開始時刻をカスタマイズできます。
 
@@ -184,7 +184,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること
 
     変更フィード名をクリックすると、チェックポイント、レプリケーションレイテンシー、その他のメトリックなど、変更フィードに関する詳細情報が表示されます。
 
-12. Dumplingを使用している場合は、[既存のデータをロードしました](#load-existing-data-optional)後に GC 時間を元の値 (デフォルト値は`10m` ) に戻す必要があります。
+12. Dumplingを使用して[既存のデータをロードした](#load-existing-data-optional)場合は、シンクの作成後に GC 時間を元の値 (デフォルト値は`10m` ) に戻す必要があります。
 
 ```sql
 SET GLOBAL tidb_gc_life_time = '10m';
diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md
index 2d06a3125f1aa..1a1c07c325ab2 100644
--- a/tidb-cloud/data-service-api-key.md
+++ b/tidb-cloud/data-service-api-key.md
@@ -108,7 +108,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access
 
     3.  （オプション）APIキーの希望するレート制限を設定します。
 
-        1 分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1 分あたり 1000 リクエスト (rpm) を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ます。
+        1 分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1 分あたり 1000 リクエスト (rpm) を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ことができます。
 
     4.  （オプション）APIキーの有効期限を設定します。
 
diff --git a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
index 13dadcd5847e2..dd91177d14956 100644
--- a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
+++ b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
@@ -5,11 +5,11 @@ summary: データ移行時に発生する事前チェックエラー、移行
 
 # データ移行に関する事前チェックエラー、移行エラー、およびアラート {#precheck-errors-migration-errors-and-alerts-for-data-migration}
 
-このドキュメントでは[データ移行を使用してデータを移行します](/tidb-cloud/migrate-from-mysql-using-data-migration.md)ときに、事前チェック エラーを解決し、移行エラーをトラブルシューティングし、アラートを購読する方法について説明します。
+このドキュメントでは[データ移行を使用してデータを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)ときに、事前チェック エラーを解決し、移行エラーをトラブルシューティングし、アラートを購読する方法について説明します。
 
 ## 事前チェックのエラーと解決策 {#precheck-errors-and-solutions}
 
-このセクションでは、データ移行時の事前チェック エラーと対応する解決策について説明します。これらのエラーは[データ移行を使用してデータを移行します](/tidb-cloud/migrate-from-mysql-using-data-migration.md)ときに**[事前チェック]**ページに表示されます。
+このセクションでは、データ移行時の事前チェック エラーと対応する解決策について説明します。これらのエラーは[データ移行を使用してデータを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)ときに**[事前チェック]**ページに表示されます。
 
 解決策は、使用している上位データベースによって異なります。
 
diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md
index 1eeedde6684f5..30f785d78531c 100644
--- a/tidb-troubleshooting-map.md
+++ b/tidb-troubleshooting-map.md
@@ -175,7 +175,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ
 
         TiDB では、計算結果は MySQL と同じですが、 `Decimal`を表すデータ構造内では、小数点精度のフィールドが実際の精度を保持します。
 
-        `(0.1^30) / 10`例にとってみましょう。TiDB と MySQL の結果はどちらも`0`です。これは、精度が最大でも`30`だからです。ただし、TiDB では、10 進精度のフィールドは依然として`31`です。
+        `(0.1^30) / 10`を例にとってみましょう。TiDB と MySQL の結果はどちらも`0`です。これは、精度が最大でも`30`だからです。ただし、TiDB では、10 進精度のフィールドは依然として`31`です。
 
         `Decimal`の除算を複数回行った後、結果は正しいものの、この精度フィールドはどんどん大きくなり、最終的に TiDB のしきい値 ( `72`超え、 `Data Truncated`エラーが報告されます。
 
diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md
index 5c36a3d6599a8..2c19fc5af062e 100644
--- a/tiflash/tiflash-command-line-flags.md
+++ b/tiflash/tiflash-command-line-flags.md
@@ -26,9 +26,9 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま
 
 -   パラメータ:
     -   `--imitative` : DTFile の暗号化機能を使用しない場合は、このフラグを使用して構成ファイルの使用と PD への接続を回避できます。
-    -   `--version` : DTFileのターゲットバージョン。値のオプションは`1` 、 `2` （デフォルト）、 `3`です。 `1`は古いバージョン、 `2`は新しいチェックサムに対応するバージョン、 `3`小さなファイルのマージをサポートするバージョンです。
-    -   `--algorithm` : データ検証に使用するハッシュアルゴリズム。値の選択肢は`xxh3` （デフォルト）、 `city128` 、 `crc32` 、 `crc64` 、 `none`です。このパラメータは`version`が`2`場合にのみ有効です。
-    -   `--frame` : 検証フレームのサイズ。デフォルト値は`1048576`です。このパラメータは`version`が`2`場合にのみ有効です。
+    -   `--version` : DTFileのターゲットバージョン。値のオプションは`1` 、 `2` （デフォルト）、 `3`です。 `1`は古いバージョン、 `2`は新しいチェックサムに対応するバージョン、 `3`は小さなファイルのマージをサポートするバージョンです。
+    -   `--algorithm` : データ検証に使用するハッシュアルゴリズム。値の選択肢は`xxh3` （デフォルト）、 `city128` 、 `crc32` 、 `crc64` 、 `none`です。このパラメータは`version`が`2`の場合にのみ有効です。
+    -   `--frame` : 検証フレームのサイズ。デフォルト値は`1048576`です。このパラメータは`version`が`2`の場合にのみ有効です。
     -   `--compression` : 対象の圧縮アルゴリズム。値のオプションは`LZ4` （デフォルト）、 `LZ4HC` 、 `zstd` 、 `none`です。
     -   `--level` : 目標圧縮レベル。指定しない場合は、圧縮アルゴリズムに応じて推奨圧縮レベルがデフォルトで使用されます。2 `compression` `LZ4`または`zstd`に設定されている場合、デフォルトのレベルは 1 です。8 `compression` `LZ4HC`に設定されている場合、デフォルトのレベルは 9 です。
     -   `--config-file` : `dttool migrate`の設定ファイルは[`server`の設定ファイル](/tiflash/tiflash-command-line-flags.md#server---config-file)と同じです。詳細については`--imitative`参照してください。
diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md
index 9b4d1a1f228f5..3658833566945 100644
--- a/tiflash/tune-tiflash-performance.md
+++ b/tiflash/tune-tiflash-performance.md
@@ -355,7 +355,7 @@ mysql> explain analyze select a, count(*) from t group by a;
 
 ### <code>tiflash_fine_grained_shuffle_stream_count</code>を設定する {#configure-code-tiflash-fine-grained-shuffle-stream-count-code}
 
-Fine Grained Shuffle 機能を[`tiflash_fine_grained_shuffle_stream_count`](/system-variables.md#tiflash_fine_grained_shuffle_stream_count-new-in-v620)設定することで、ウィンドウ関数の実行における同時実行性を高めることができます。これにより、ウィンドウ関数の実行により多くのシステムリソースが使用されるようになり、クエリのパフォーマンスが向上します。
+Fine Grained Shuffle 機能の[`tiflash_fine_grained_shuffle_stream_count`](/system-variables.md#tiflash_fine_grained_shuffle_stream_count-new-in-v620)を設定することで、ウィンドウ関数の実行における同時実行性を高めることができます。これにより、ウィンドウ関数の実行により多くのシステムリソースが使用されるようになり、クエリのパフォーマンスが向上します。
 
 ウィンドウ関数がTiFlashにプッシュダウンされて実行される際、この変数を使用してウィンドウ関数実行の同時実行レベルを制御できます。単位はスレッドです。
 
@@ -363,7 +363,7 @@ Fine Grained Shuffle 機能を[`tiflash_fine_grained_shuffle_stream_count`](/sys
 set @@tiflash_fine_grained_shuffle_stream_count = 20;
 ```
 
-次の例は、変数`tiflash_fine_grained_shuffle_stream_count`が再構成される前後のクエリ結果を示しています。再構成前は、 `[ExchangeSender_11, ExchangeReceiver_12, Sort_13, Window_22]`のうち`stream_count` 8 です。再構成後は、 `stream_count` 20 になります。
+次の例は、変数`tiflash_fine_grained_shuffle_stream_count`が再構成される前後のクエリ結果を示しています。再構成前は、 `[ExchangeSender_11, ExchangeReceiver_12, Sort_13, Window_22]`のうち`stream_count`は 8 です。再構成後は、 `stream_count`は 20 になります。
 
 `tiflash_fine_grained_shuffle_stream_count`が再構成される前:
 
diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md
index b5f1418b59cdb..2a058f224071a 100644
--- a/tiup/tiup-component-cluster-patch.md
+++ b/tiup/tiup-component-cluster-patch.md
@@ -31,7 +31,7 @@ tiup cluster patch <cluster-name> <package-path> [flags]
     -   `${component}` : 置換するコンポーネントの名前 ( `tidb` 、 `tikv` 、 `pd`など)。
     -   `${version}` :コンポーネントのバージョン ( `v8.5.3`や`v7.5.4`など)。
     -   `${os}` :オペレーティングシステム（ `linux` ）。
-    -   `${arch}` :コンポーネント`arm64`実行されるプラットフォーム( `amd64` )。
+    -   `${arch}` :コンポーネントが実行されるプラットフォーム ( `amd64` 、 `arm64` )。
 
 2.  次のコマンドを使用して、現在のコンポーネントパッケージをダウンロードします。