diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md
index 59ee872255126..7f7080bf202eb 100644
--- a/br/br-checkpoint-backup.md
+++ b/br/br-checkpoint-backup.md
@@ -23,7 +23,7 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを
## 使用制限 {#usage-limitations}
-チェックポイント・バックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元することはできません。詳細については、以下のセクションで説明します。
+チェックポイント・バックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元できるわけではありません。詳細については、以下のセクションで説明します。
### バックアップの再試行はGCの前に行う必要があります {#backup-retry-must-be-prior-to-gc}
diff --git a/dm/dm-faq.md b/dm/dm-faq.md
index f610439f922af..2673e16c7bf13 100644
--- a/dm/dm-faq.md
+++ b/dm/dm-faq.md
@@ -32,7 +32,7 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを
> **Note:**
>
-> 現在、TiDBはMySQLがサポートするすべてのDDL文と互換性がありません[MySQLの互換性](/mysql-compatibility.md#ddl-operations)参照してください。
+> 現在、TiDBはMySQLがサポートするすべてのDDL文と互換性があるわけではありません[MySQLの互換性](/mysql-compatibility.md#ddl-operations)を参照してください。
## DM はビュー関連の DDL ステートメントと DML ステートメントを TiDB に複製しますか? {#does-dm-replicate-view-related-ddl-statements-and-dml-statements-to-tidb}
@@ -388,4 +388,4 @@ dmctl execute コマンドを使用すると、DM マスターへの接続に失
## ロード ユニットがUnknown character setエラーを報告するのはなぜですか? {#why-does-the-load-unit-report-the-code-unknown-character-set-code-error}
-TiDBはMySQLのすべての文字セットをサポートしていません。そのため、フルインポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、DMはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。
+TiDBはMySQLのすべての文字セットをサポートしているわけではありません。そのため、フルインポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、DMはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。
diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md
index a93fbe0991e4e..f5f288e030b76 100644
--- a/dm/feature-shard-merge-pessimistic.md
+++ b/dm/feature-shard-merge-pessimistic.md
@@ -121,7 +121,7 @@ sequenceDiagram
データ移行中に特にDDLステートメントが処理されない場合、 `table_1`のDDLステートメントがダウンストリームに移行され、ダウンストリームのテーブルスキーマが変更されると、 `schema V1`からの`table_2` }のDMLステートメントは正常に移行されません。そのため、単一のDMワーカー内で、 `DM-master`内のものと同様の論理シャーディンググループが作成されますが、このグループのメンバーは、同じアップストリームMySQLインスタンス内の異なるシャーディングテーブルになります。
-しかし、DMワーカーがシャーディンググループの移行を内部で調整する場合、それは`DM-master`によって実行されるものとは完全に同じではありません。理由は以下のとおりです。
+しかし、DMワーカーがシャーディンググループの移行を内部で調整する場合、それは`DM-master`によって実行されるものとは完全には同じではありません。理由は以下のとおりです。
- DM-worker が`table_1`の DDL ステートメントを受信すると、移行を一時停止することはできず、binlogの解析を続行して、後続の`table_2`の DDL ステートメントを取得する必要があります。つまり`t2`と`t3`の間の解析を続行する必要があります。
- `t2`と`t3`間のbinlog解析処理中、シャーディング DDL ステートメントが移行され、正常に実行されるまで、 `schema V2`の`table_1`の DML ステートメントはダウンストリームに移行できません。
diff --git a/faq/sql-faq.md b/faq/sql-faq.md
index 90db954e13360..96d4fdd6426d4 100644
--- a/faq/sql-faq.md
+++ b/faq/sql-faq.md
@@ -291,7 +291,7 @@ v6.4.0 以降、TiDB は[メタデータロックメカニズム](/metadata-lock
> **Note:**
>
-> - 現在、TiDB はバージョン`schema`の変更をすべてキャッシュしません。
+> - 現在、TiDB はバージョン`schema`の変更をすべてキャッシュするわけではありません。
> - 各 DDL 操作では、 `schema`バージョンの変更の数は、対応する`schema state`バージョンの変更の数と同じです。
> - DDL操作によって、バージョン`schema`の変更回数は異なります。例えば、 `CREATE TABLE`文ではバージョン`schema`変更が1回発生しますが、 `ADD COLUMN`文ではバージョン5の変更が4回発生します。
diff --git a/functions-and-operators/date-and-time-functions.md b/functions-and-operators/date-and-time-functions.md
index 1e86cb8dfdf90..a727d4931101e 100644
--- a/functions-and-operators/date-and-time-functions.md
+++ b/functions-and-operators/date-and-time-functions.md
@@ -81,7 +81,7 @@ TiDB は、MySQL 8.0 で利用可能な[日付と時刻関数](https://dev.mysql
## MySQLの互換性 {#mysql-compatibility}
-関数`STR_TO_DATE()` TiDBでサポートされていますが、すべての日付と時刻の値を解析することはできません。また、以下の日付と時刻のフォーマットオプションは**実装されていません**。
+関数`STR_TO_DATE()` TiDBでサポートされていますが、すべての日付と時刻の値を解析できるわけではありません。また、以下の日付と時刻のフォーマットオプションは**実装されていません**。
| 形式 | 説明 |
| -------------- | -------------------------------------------------- |
diff --git a/identify-slow-queries.md b/identify-slow-queries.md
index 75433fa271d97..09222467672cf 100644
--- a/identify-slow-queries.md
+++ b/identify-slow-queries.md
@@ -68,8 +68,8 @@ insert into t select * from t;
- `439478225786634241` : 内部バージョン。
- `105000` : 統計情報における行の総数。
- `5000` : 前回の統計収集以降に変更された行数。
- - `col1:allEvicted` : 列`col1`の統計情報が完全に読み込まれていません。
- - `idx1:allEvicted` : インデックス`idx1`の統計情報が完全に読み込まれていません。
+ - `col1:allEvicted` : 列`col1`の統計情報が完全には読み込まれていません。
+ - `idx1:allEvicted` : インデックス`idx1`の統計情報が完全には読み込まれていません。
- `Succ` : ステートメントが正常に実行されたかどうか。
- `Backoff_time` : ステートメントが再試行を必要とするエラーに遭遇した場合の、再試行までの待機時間。このような一般的なエラーには、 `lock occurs` 、 `Region split` 、および`tikv server is busy`などがあります。
- `Plan` : ステートメントの実行プラン。 `SELECT tidb_decode_plan('xxx...')`ステートメントを実行して、具体的な実行プランを解析します。
diff --git a/partitioned-table.md b/partitioned-table.md
index 9d349cc872576..697cea7dc335c 100644
--- a/partitioned-table.md
+++ b/partitioned-table.md
@@ -1490,7 +1490,7 @@ PARTITION BY HASH( YEAR(col2) )
PARTITIONS 4;
```
-上記の例では、主キーにパーティショニング式で参照されているすべての列が含まれていません。主キーに不足している列を追加すると、 `CREATE TABLE`ステートメントが有効になります。
+上記の例では、主キーにパーティショニング式で参照されているすべての列が含まれているわけではありません。主キーに不足している列を追加すると、 `CREATE TABLE`ステートメントが有効になります。
```sql
CREATE TABLE t5 (
diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md
index 8b3f8a7769dbf..8e48dbf2a8987 100644
--- a/releases/release-6.5.0.md
+++ b/releases/release-6.5.0.md
@@ -367,7 +367,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では
### その他 {#others}
- v6.5.0 以降、 `mysql.user`テーブルに`Password_reuse_history`と`Password_reuse_time` 2 つの新しい列が追加されます。
-- バージョン6.5.0以降、 [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能がデフォルトで有効になっています。この機能は[1つの`ALTER TABLE`文で複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)と完全に互換性がありません。インデックスアクセラレーションを使用して一意インデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能は[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 [ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)参照してください。
+- バージョン6.5.0以降、 [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能がデフォルトで有効になっています。この機能は[1つの`ALTER TABLE`文で複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)と完全には互換性がありません。インデックスアクセラレーションを使用して一意インデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能は[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 [ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)を参照してください。
## 非推奨の機能 {#deprecated-feature}
diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md
index fc841b260f7f6..fc4ba58cbb2e7 100644
--- a/releases/release-7.3.0.md
+++ b/releases/release-7.3.0.md
@@ -59,7 +59,7 @@ TiDB バージョン: 7.3.0
- 予想以上にリソースを使用するクエリを手動でマークする (実験的) [#43691](https://github.com/pingcap/tidb/issues/43691) @[Connor1996](https://github.com/Connor1996) @[CabinfeverB](https://github.com/CabinfeverB)
- TiDB v7.2.0では、想定以上のリソースを使用するクエリ（暴走クエリ）を自動的にダウングレードまたはキャンセルすることで、TiDBが自動的に管理します。しかし、実際の運用では、ルールだけではすべてのケースに対応できません。そこで、TiDB v7.3.0では、暴走クエリを手動でマークする機能が導入されました。新しいコマンド[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を使用すると、SQLテキスト、SQLダイジェスト、または実行プランに基づいて暴走クエリをマークでき、マークされた暴走クエリをダウングレードまたはキャンセルできます。
+ TiDB v7.2.0では、想定以上のリソースを使用するクエリ（暴走クエリ）を自動的にダウングレードまたはキャンセルすることで、TiDBが自動的に管理します。しかし、実際の運用では、ルールだけではすべてのケースに対応できるわけではありません。そこで、TiDB v7.3.0では、暴走クエリを手動でマークする機能が導入されました。新しいコマンド[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を使用すると、SQLテキスト、SQLダイジェスト、または実行プランに基づいて暴走クエリをマークでき、マークされた暴走クエリをダウングレードまたはキャンセルできます。
この機能は、データベースにおける突発的なパフォーマンス問題に対する効果的な介入手段を提供します。クエリによって引き起こされるパフォーマンス問題の場合、根本原因を特定する前に、この機能によって全体的なパフォーマンスへの影響を迅速に軽減し、システムサービスの品質を向上させることができます。
diff --git a/sql-mode.md b/sql-mode.md
index 2e933f20f67c7..9c05923643275 100644
--- a/sql-mode.md
+++ b/sql-mode.md
@@ -40,7 +40,7 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ
| `STRICT_ALL_TABLES` | トランザクションテーブルの場合、無効な値が挿入された後にトランザクションステートメント全体をロールバックします。（完全サポート） |
| `NO_ZERO_IN_DATE` | 厳格モードでは、月または日の一部が`0`である日付は受け入れられません。 `IGNORE`オプションを使用すると、TiDB は同様の日付に対して '0000-00-00' を挿入します。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） |
| `NO_ZERO_DATE` | 厳格モードでは、「0000-00-00」を有効な日付として使用しません。ただし`IGNORE`オプションを使用すれば、ゼロの日付を挿入することは可能です。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） |
-| `ALLOW_INVALID_DATES` | このモードでは、システムはすべての日付の有効性をチェックしません。 `1`から`12`までの月の値と、 `1`から`31` }までの日付の値のみをチェックします。このモードは`DATE`列と`DATATIME`列にのみ適用されます。 `TIMESTAMP`列はすべて完全な有効性チェックが必要です。（完全サポート） |
+| `ALLOW_INVALID_DATES` | このモードでは、システムはすべての日付の有効性をチェックするわけではありません。 `1`から`12`までの月の値と、 `1`から`31` }までの日付の値のみをチェックします。このモードは`DATE`列と`DATATIME`列にのみ適用されます。 `TIMESTAMP`列はすべて完全な有効性チェックが必要です。（完全サポート） |
| `ERROR_FOR_DIVISION_BY_ZERO` | このモードが有効になっている場合、システムはデータ変更操作（ `0`または`INSERT`で`UPDATE`による除算を処理する際にエラーを返します。
このモードが有効になっていない場合、システムは警告を返し、代わりに`NULL`が使用されます。（完全サポート） |
| `NO_AUTO_CREATE_USER` | `GRANT` 、指定されたパスワード以外の新規ユーザーを自動的に作成することを防止します（完全サポート）。 |
| `HIGH_NOT_PRECEDENCE` | NOT演算子の優先順位は、 `NOT a BETWEEN b AND c`のような式`NOT (a BETWEEN b AND c)`として解析されるように設定されています。MySQLの古いバージョンでは、この式は`(NOT a) BETWEEN b AND c`として解析されます。（完全サポート） |
diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md
index c4aa08b6ebed1..92cbdc502d937 100644
--- a/sql-statements/sql-statement-admin-checksum-table.md
+++ b/sql-statements/sql-statement-admin-checksum-table.md
@@ -12,7 +12,7 @@ category: reference
[チェックサム](/tidb-lightning/tidb-lightning-glossary.md#checksum) 、テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。
-[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。
+[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `が実行されます。
diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md
index a202df09b9256..c24244e7679db 100644
--- a/tidb-lightning/troubleshoot-tidb-lightning.md
+++ b/tidb-lightning/troubleshoot-tidb-lightning.md
@@ -174,7 +174,7 @@ TiDB Lightning Local-backend は、v4.0.0 以降のバージョンの TiDB ク
### `Unknown character set` {#unknown-character-set}
-TiDBはMySQLのすべての文字セットをサポートしていません。そのため、インポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、 TiDB Lightningはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)使用して下流で事前にテーブルスキーマを作成してください。
+TiDBはMySQLのすべての文字セットをサポートしているわけではありません。そのため、インポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、 TiDB Lightningはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。
### `invalid compression type ...` {#invalid-compression-type}
diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md
index 7a5682af1e752..565486da621ac 100644
--- a/two-data-centers-in-one-city-deployment.md
+++ b/two-data-centers-in-one-city-deployment.md
@@ -29,8 +29,8 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ
このデプロイメントソリューションでは、クラスタのレプリケーション状態を制御および識別するために3つのステータスを定義しており、これによりTiKVのレプリケーションモードが制限されます。クラスタのレプリケーションモードは、3つのステータス間を自動的かつ適応的に切り替えることができます。詳細については、セクション[ステータススイッチ](#status-switch)ご覧ください。
- **sync** : 同期レプリケーションモード。このモードでは、災害復旧AZ内の少なくとも1つのレプリカがプライマリAZと同期します。RaftRaftにより、各ログはラベルに基づいてDRに複製されます。
-- **async** : 非同期レプリケーションモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全に同期されません。RaftアルゴリズムはRaftプロトコルに従ってログを複製します。
-- **sync-recover** : 同期リカバリモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全に同期されていません。Raftは徐々にラベルレプリケーションモードに切り替え、ラベル情報をPDに報告します。
+- **async** : 非同期レプリケーションモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されません。RaftアルゴリズムはRaftプロトコルに従ってログを複製します。
+- **sync-recover** : 同期リカバリモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されていません。Raftは徐々にラベルレプリケーションモードに切り替え、ラベル情報をPDに報告します。
## コンフィグレーション {#configuration}