pingcap · yahonda · Jul 21, 2026
diff --git 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
@@ -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 マスターへの接続に失
 
 ## ロード ユニットが<code>Unknown character set</code>エラーを報告するのはなぜですか? {#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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -40,7 +40,7 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ
 | `STRICT_ALL_TABLES`          | トランザクションテーブルの場合、無効な値が挿入された後にトランザクションステートメント全体をロールバックします。（完全サポート）                                                                                                                                                                                                                                   |
 | `NO_ZERO_IN_DATE`            | 厳格モードでは、月または日の一部が`0`である日付は受け入れられません。 `IGNORE`オプションを使用すると、TiDB は同様の日付に対して &#39;0000-00-00&#39; を挿入します。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート）                                                                                                                                                    |
 | `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`による除算を処理する際にエラーを返します。<br/>このモードが有効になっていない場合、システムは警告を返し、代わりに`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
@@ -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 <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 <table>`が実行されます。
 
 </CustomContent>
 

diff --git 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}