-v5.4.0以降のバージョンでは、 `enable-relay`を`true`に設定することでリレーログを有効にできます。v5.4.0以降では、上流データソースをバインドする際に、DM-workerはデータソースの設定で`enable-relay`をチェックします。 `enable-relay`が`true`場合、このデータソースに対してリレーログ機能が有効になります。
+v5.4.0以降のバージョンでは、 `enable-relay`を`true`に設定することでリレーログを有効にできます。v5.4.0以降では、上流データソースをバインドする際に、DM-workerはデータソースの設定で`enable-relay`をチェックします。 `enable-relay`が`true`の場合、このデータソースに対してリレーログ機能が有効になります。
詳しい設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。
@@ -56,7 +56,7 @@ start-relay -s mysql-replica-01
> **Note:**
>
-> DM v2.0.2 以降の DM v2.0.x および v5.3.0 では、ソース設定ファイル内の設定項目`enable-relay`無効になっており、リレーログの有効化と無効化には`start-relay`と`stop-relay`のみを使用できます。DM は、 [データソース構成の読み込み](/dm/dm-manage-source.md#operate-data-source)ときに`enable-relay` `true`に設定されていることを検出した場合、以下のメッセージを出力します。
+> DM v2.0.2 以降の DM v2.0.x および v5.3.0 では、ソース設定ファイル内の設定項目`enable-relay`は無効になっており、リレーログの有効化と無効化には`start-relay`と`stop-relay`のみを使用できます。DM は、 [データソース構成の読み込み](/dm/dm-manage-source.md#operate-data-source)のときに`enable-relay`が`true`に設定されていることを検出した場合、以下のメッセージを出力します。
>
> Please use `start-relay` to specify which workers should pull relay log of relay-enabled sources.
@@ -310,7 +310,7 @@ purge:
- アップストリームでプライマリ インスタンスとセカンダリ インスタンスが切り替わると、DM-worker は増分シリアル番号を持つ新しい`subdir`ディレクトリを生成します。
- - 上記の例では、ディレクトリ`7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001`場合、 `7e427cc0-091c-11e9-9e45-72b7c59d52d7`アップストリーム データベース UUID であり、 `000001`ローカル`subdir`シリアル番号です。
+ - 上記の例では、ディレクトリ`7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001`の場合、 `7e427cc0-091c-11e9-9e45-72b7c59d52d7`はアップストリーム データベース UUID であり、 `000001`はローカル`subdir`シリアル番号です。
- `server-uuid.index` : 現在利用可能な`subdir`ディレクトリのリストを記録します。
diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md
index 2ca3e465dd058..2feb2338ac4e3 100644
--- a/dr-secondary-cluster.md
+++ b/dr-secondary-cluster.md
@@ -159,7 +159,7 @@ nohup ./minio server ./data --address :6060 &
SELECT @@global.tidb_gc_enable;
```
- 値が`0`場合は、GCが無効になっていることを意味します。
+ 値が`0`の場合は、GCが無効になっていることを意味します。
+-------------------------+
| @@global.tidb_gc_enable |
@@ -259,7 +259,7 @@ nohup ./minio server ./data --address :6060 &
SELECT @@global.tidb_gc_enable;
```
- 値が`1`場合は、GCが有効になっていることを意味します。
+ 値が`1`の場合は、GCが有効になっていることを意味します。
+-------------------------+
| @@global.tidb_gc_enable |
diff --git a/dynamic-config.md b/dynamic-config.md
index d254657886f3f..11a5bc6fc25cc 100644
--- a/dynamic-config.md
+++ b/dynamic-config.md
@@ -239,7 +239,7 @@ show warnings;
上記の表で、プレフィックスが`{db-name}`または`{db-name}.{cf-name}`パラメータはRocksDB関連の設定です。5のオプション値は`db-name` `rocksdb` `raftdb`です。
- `db-name`が`rocksdb`の場合、 `cf-name`のオプションの値は`defaultcf` 、 `writecf` 、 `lockcf` 、および`raftcf`です。
-- `db-name`が`raftdb`とき、 `cf-name`の値は`defaultcf`になります。
+- `db-name`が`raftdb`のとき、 `cf-name`の値は`defaultcf`になります。
詳細なパラメータの説明については[TiKVコンフィグレーションファイル](/tikv-configuration-file.md)を参照してください。
diff --git a/encryption-at-rest.md b/encryption-at-rest.md
index 3ecfc18555a5f..2bcba2d8f5135 100644
--- a/encryption-at-rest.md
+++ b/encryption-at-rest.md
@@ -82,7 +82,7 @@ TiKVは現在、 CTRモードでAES128、AES192、AES256、またはSM4（バー
- `data-key-rotation-period` 、TiKV がキーをローテーションする頻度を指定します。
-暗号化が有効になっている場合（つまり、 `data-encryption-method`値が`"plaintext"`ではない場合）、次のいずれかの方法でマスター キーを指定する必要があります。
+暗号化が有効になっている場合（つまり、 `data-encryption-method`の値が`"plaintext"`ではない場合）、次のいずれかの方法でマスター キーを指定する必要があります。
- [KMS経由でマスターキーを指定する](#specify-a-master-key-via-kms)
- [ファイル経由でマスターキーを指定する](#specify-a-master-key-via-a-file)
diff --git a/error-codes.md b/error-codes.md
index 01f4113a20504..61038376cb553 100644
--- a/error-codes.md
+++ b/error-codes.md
@@ -225,7 +225,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合
プラグイン ID の形式が正しくありません。
- 正しい形式は`[name]-[version]`あり、 `name`と`version`では`-`許可されません。
+ 正しい形式は`[name]-[version]`であり、 `name`と`version`では`-`は許可されません。
- エラー番号: 8102
diff --git a/explain-overview.md b/explain-overview.md
index 349b558a121d3..394805393c818 100644
--- a/explain-overview.md
+++ b/explain-overview.md
@@ -156,13 +156,13 @@ TiDBは、TiKV/ TiFlashからスキャンされたデータまたは計算結果
>
> - インデックスを使用するには、条件が*検索引数*可能でなければなりません。例えば、条件`YEAR(date_column) < 1992`インデックスを使用できませんが、 `date_column < '1992-01-01`では使用できます。
> - 同じタイプのデータと[文字セットと照合順序](/character-set-and-collation.md)比較することをお勧めします。タイプが混在すると、追加の`cast`操作が必要になるか、インデックスが使用できなくなる可能性があります。
-> - `AND` （積集合）と`OR` （和集合）を使用して、1つの列の範囲クエリ条件を組み合わせることもできます。多次元複合インデックスの場合は、複数の列で条件を使用できます。例えば、複合インデックス`(a, b, c)`場合：
+> - `AND` （積集合）と`OR` （和集合）を使用して、1つの列の範囲クエリ条件を組み合わせることもできます。多次元複合インデックスの場合は、複数の列で条件を使用できます。例えば、複合インデックス`(a, b, c)`の場合：
> - `a`同等のクエリである場合は、 `b`のクエリ範囲を計算し続けます。 `b`同等のクエリである場合は、 `c`のクエリ範囲を計算し続けます。
> - それ以外の場合、 `a`同等でないクエリであれば、 `a`範囲しか把握できません。
### タスクの概要 {#task-overview}
-現在、TiDBの計算タスクは、copタスクとルートタスクの2つのカテゴリに分類できます。タスク番号`cop[tikv]`場合、演算子はTiKVコプロセッサ内で実行されます。タスク番号が`root`場合、演算子はTiDB内で完了します。
+現在、TiDBの計算タスクは、copタスクとルートタスクの2つのカテゴリに分類できます。タスク番号が`cop[tikv]`の場合、演算子はTiKVコプロセッサ内で実行されます。タスク番号が`root`の場合、演算子はTiDB内で完了します。
SQL最適化の目標の一つは、計算を可能な限りTiKVに委ねることです。TiKVのコプロセッサーは、組み込みSQL関数（集計関数とスカラー関数を含む）、SQL `LIMIT`演算、インデックススキャン、テーブルスキャンのほとんどをサポートしています。
diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md
index 2bfaa2988f863..0aeaed3cbd143 100644
--- a/functions-and-operators/group-by-modifier.md
+++ b/functions-and-operators/group-by-modifier.md
@@ -104,11 +104,11 @@ SELECT year, month, SUM(profit) AS profit from bank GROUP BY year, month WITH RO
具体的には：
-- 最初の行の`profit`値は 2 次元グループ`{year, month}`からのもので、細粒度`{2000, "Jan"}`グループに対する集計結果を表しています。
+- 最初の行の`profit`の値は 2 次元グループ`{year, month}`からのもので、細粒度`{2000, "Jan"}`グループに対する集計結果を表しています。
- 2 行目の値`profit`は 1 次元グループ`{year}`からのもので、中間レベルのグループ`{2001}`の集計結果を表しています。
-- 最後の行の`profit`値は 0 次元のグループ化`{}`から取得され、全体的な集計結果を表します。
+- 最後の行の`profit`の値は 0 次元のグループ化`{}`から取得され、全体的な集計結果を表します。
-`WITH ROLLUP`結果のうち`NULL`値は、Aggregate 演算子が適用される直前に生成されます。したがって、 `SELECT` 、 `HAVING` 、 `ORDER BY`句で`NULL`値を使用して、集計結果をさらに絞り込むことができます。
+`WITH ROLLUP`の結果のうち`NULL`値は、Aggregate 演算子が適用される直前に生成されます。したがって、 `SELECT` 、 `HAVING` 、 `ORDER BY`句で`NULL`値を使用して、集計結果をさらに絞り込むことができます。
たとえば、 `HAVING`句の`NULL`使用して、2 次元グループの集計結果のみをフィルタリングして表示できます。
diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md
index bf33fc04d5a2b..025fc131ce0e4 100644
--- a/functions-and-operators/string-functions.md
+++ b/functions-and-operators/string-functions.md
@@ -20,8 +20,8 @@ Oracle と TiDB の関数と構文の比較については、 [Oracle と TiDB
`ASCII(str)`関数は、指定された引数の左端の文字のASCII値を取得するために使用されます。引数は文字列または数値のいずれかです。
- 引数が空でない場合、関数は左端の文字の ASCII 値を返します。
-- 引数が空の文字列の場合、関数は`0`返します。
-- 引数が`NULL`の場合、関数は`NULL`返します。
+- 引数が空の文字列の場合、関数は`0`を返します。
+- 引数が`NULL`の場合、関数は`NULL`を返します。
> **Note:**
>
@@ -50,9 +50,9 @@ SELECT ASCII('A'), ASCII('TiDB'), ASCII(23);
- 引数が正の数の場合、関数はそのバイナリ値の文字列表現を返します。
- 引数が負の数の場合、関数は引数の絶対値をその 2 進表現に変換し、2 進値の各ビットを反転し ( `0`を`1`に、 `1`を`0`に変更)、反転した値に`1`加算します。
- 引数が数字のみを含む文字列の場合、関数はその数字に応じた結果を返します。例えば、 `"123"`と`123`の結果は同じになります。
-- 引数が文字列で、その最初の文字が数字ではない場合 ( `"q123"`など)、関数は`0`返します。
-- 引数が数字と非数字を含む文字列の場合、関数は引数の先頭の連続する数字に基づいて結果を返します。例えば、 `"123q123"`と`123`の結果は同じですが、 `BIN('123q123')`場合は`Truncated incorrect INTEGER value: '123q123'`ような警告が生成されます。
-- 引数が`NULL`の場合、関数は`NULL`返します。
+- 引数が文字列で、その最初の文字が数字ではない場合 ( `"q123"`など)、関数は`0`を返します。
+- 引数が数字と非数字を含む文字列の場合、関数は引数の先頭の連続する数字に基づいて結果を返します。例えば、 `"123q123"`と`123`の結果は同じですが、 `BIN('123q123')`の場合は`Truncated incorrect INTEGER value: '123q123'`のような警告が生成されます。
+- 引数が`NULL`の場合、関数は`NULL`を返します。
例1:
@@ -360,7 +360,7 @@ SELECT CONCAT_WS(',', 'TiDB Server', 'TiKV', 'PD');
+----------------------------------------------+
```
-- 連結される引数の 1 つだけが`NULL`でない場合、 `CONCAT_WS()`その引数を返します。
+- 連結される引数の 1 つだけが`NULL`でない場合、 `CONCAT_WS()`はその引数を返します。
例：
@@ -444,8 +444,8 @@ EXPORT_SET(bits, on, off, [separator[, number_of_bits]])
```
- `bits` : ビット値を表す整数。
-- `on` : 対応するビットが`1`場合に返される文字列。
-- `off` : 対応するビットが`0`場合に返される文字列。
+- `on` : 対応するビットが`1`の場合に返される文字列。
+- `off` : 対応するビットが`0`の場合に返される文字列。
- `separator` (オプション): 結果文字列の区切り文字。
- `number_of_bits` （オプション）: 処理するビット数。設定されていない場合は、デフォルトで`64` （最大ビット数）が使用され、 `bits`符号なし64ビット整数として扱われます。
@@ -537,8 +537,8 @@ SELECT FIND_IN_SET('Go', 'COBOL,BASIC,Rust,Go,Java,Fortran');
引数:
- `X` : 書式設定する数値。数値、数値文字列、または科学的記数法の数値を指定できます。
-- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。8 `X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。
-- `[locale]` : 小数点の区切り、千単位の区切り、および結果の数値の区切りに使用するロケール設定を指定します。有効なロケール値は、システム変数[`lc_time_names`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lc_time_names)の有効な値と同じです。指定されていない場合、または地域設定が`NULL`場合、デフォルトで地域設定`'en_US'`が使用されます。この引数はオプションです。
+- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。`X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。
+- `[locale]` : 小数点の区切り、千単位の区切り、および結果の数値の区切りに使用するロケール設定を指定します。有効なロケール値は、システム変数[`lc_time_names`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lc_time_names)の有効な値と同じです。指定されていない場合、または地域設定が`NULL`の場合、デフォルトで地域設定`'en_US'`が使用されます。この引数はオプションです。
動作:
@@ -632,8 +632,8 @@ mysql> SELECT FROM_BASE64('MTIzNDU2');
`HEX()`関数は、指定された引数をその16進数値の文字列表現に変換します。引数は文字列または数値のいずれかです。
- 引数が文字列の場合、 `HEX(str)` `str`の16進文字列表現を返します。この関数は、 `str`の各文字の各バイトを2桁の16進数に変換します。例えば、UTF-8またはASCII文字セットの文字`a` 2進値では`00111101` 、16進表記では`61`として表されます。
-- 引数が数値の場合、 `HEX(n)` `n`の16進文字列表現を返します。この関数は引数`n` `BIGINT`として扱い、これは`CONV(n, 10, 16)`使用するのと同じ意味になります。
-- 引数が`NULL`の場合、関数は`NULL`返します。
+- 引数が数値の場合、 `HEX(n)` `n`の16進文字列表現を返します。この関数は引数`n` `BIGINT`として扱い、これは`CONV(n, 10, 16)`を使用するのと同じ意味になります。
+- 引数が`NULL`の場合、関数は`NULL`を返します。
> **Note:**
>
@@ -1248,7 +1248,7 @@ SELECT LOCATE(_binary'B', 'aBcde');
- 引数が文字列の場合、関数は小文字で文字列を返します。
- 引数が数値の場合、関数は先頭のゼロを除いた数値を返します。
-- 引数が`NULL`の場合、関数は`NULL`返します。
+- 引数が`NULL`の場合、関数は`NULL`を返します。
例:
@@ -2106,7 +2106,7 @@ TO_BASE64(str)
```
- 引数が文字列でない場合、関数はそれを base-64 エンコードする前に文字列に変換します。
-- 引数が`NULL`の場合、関数は`NULL`返します。
+- 引数が`NULL`の場合、関数は`NULL`を返します。
例1:
diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md
index 168be1a46d220..58a6018c8a01f 100644
--- a/functions-and-operators/tidb-functions.md
+++ b/functions-and-operators/tidb-functions.md
@@ -573,7 +573,7 @@ TIDB_ENCODE_INDEX_KEY(
, , , ...,
- `...` : インデックス列の値。インデックスで定義されている順序と同じ順序で値を指定する必要があります。複合インデックスの場合は、すべてのインデックス列の値を指定する必要があります。
- `...` : 行のハンドル値。必要なハンドル値は、テーブルの主キーの種類によって異なります。
- - テーブルに主キーがない場合、または主キーが`NONCLUSTERED`場合、ハンドル値は非表示の列`_tidb_rowid`の値になります。
+ - テーブルに主キーがない場合、または主キーが`NONCLUSTERED`の場合、ハンドル値は非表示の列`_tidb_rowid`の値になります。
- 主キーが`CLUSTERED`で、単一列の整数の場合、ハンドル値は主キー列の値になります。
- 主キーが`CLUSTERED`で、複合主キーまたは非整数型 (共通ハンドル) の場合、ハンドル値はすべての主キー列の値を順番に含んだものになります。
diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md
index 715650dfe473f..072dc9cf07053 100644
--- a/grafana-resource-control-dashboard.md
+++ b/grafana-resource-control-dashboard.md
@@ -23,7 +23,7 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en
- クエリあたりのRRU: 各SQL文が1秒あたりに消費する平均読み取り要求ユニット数。上記のRRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。
- WRU: リアルタイムで計算される各リソース グループの書き込み要求単位消費情報。1 `total` 、すべてのリソース グループによって消費される書き込み要求単位の合計です。
- クエリあたりのWRU: 各SQL文が1秒あたりに消費する書き込みリクエストユニット（WRRU）の平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。
-- 利用可能なRU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`場合、このリソースグループは`RU_PER_SEC`割合でトークンを消費し、レート制限状態にあるとみなされます。
+- 利用可能なRU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`の場合、このリソースグループは`RU_PER_SEC`の割合でトークンを消費し、レート制限状態にあるとみなされます。
- クエリの最大期間: リソース グループに関する最大クエリ期間。
## リソースに関する指標 {#metrics-about-resources}
diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md
index 17a85f37bea7e..e92c3e5af75e2 100644
--- a/identify-expensive-queries.md
+++ b/identify-expensive-queries.md
@@ -22,7 +22,7 @@ TiDBを使用すると、SQL実行中に高負荷なクエリを特定できる
基本フィールド:
- `cost_time` : ログが印刷されるときのステートメントの実行時間。
-- `stats` : 文に関係するテーブルまたはインデックスで使用される統計情報のバージョン。値が`pseudo`場合、利用可能な統計情報がないことを意味します。この場合、テーブルまたはインデックスを分析する必要があります。
+- `stats` : 文に関係するテーブルまたはインデックスで使用される統計情報のバージョン。値が`pseudo`の場合、利用可能な統計情報がないことを意味します。この場合、テーブルまたはインデックスを分析する必要があります。
- `table_ids` : ステートメントに関係するテーブルの ID。
- `txn_start_ts` : トランザクションの開始タイムスタンプと一意のID。この値を使用して、トランザクション関連のログを検索できます。
- `sql` : SQL ステートメント。
diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md
index f924245610aab..e4002788f28f9 100644
--- a/information-schema/information-schema-tidb-trx.md
+++ b/information-schema/information-schema-tidb-trx.md
@@ -46,7 +46,7 @@ DESC TIDB_TRX;
- `LockWaiting` : トランザクションは悲観的ロックの取得を待機しています。他のトランザクションによってブロックされているかどうかに関係なく、トランザクションは悲観的ロック操作の開始時にこの状態になることに注意してください。
- `Committing` : トランザクションはコミット処理中です。
- `RollingBack` : トランザクションはロールバック中です。
-- `WAITING_START_TIME` : `STATE`の値が`LockWaiting`場合、この列には待機の開始時刻が表示されます。
+- `WAITING_START_TIME` : `STATE`の値が`LockWaiting`の場合、この列には待機の開始時刻が表示されます。
- `MEM_BUFFER_KEYS` : 現在のトランザクションによってメモリバッファーに書き込まれたキーの数。
- `MEM_BUFFER_BYTES` : 現在のトランザクションによってメモリバッファーに書き込まれたキー値バイトの合計数。
- `SESSION_ID` : このトランザクションが属するセッションの ID。
diff --git a/literal-values.md b/literal-values.md
index d7c79bc1f0ce3..50732a779e7ff 100644
--- a/literal-values.md
+++ b/literal-values.md
@@ -29,7 +29,7 @@ TiDBのリテラル値には、文字リテラル、数値リテラル、時刻
- バイナリ文字列: 文字セットと照合順序が両方とも`binary`あるバイトのシーケンスで構成され、比較の単位として**バイト**を使用します。
- 非バイナリ文字列: 文字のシーケンスで構成され、 `binary`以外の様々な文字セットと照合順序を持ちます。非バイナリ文字列は、**文字を**単位として互いに比較されます。文字セットによっては、1文字に複数のバイトが含まれる場合があります。
-文字列リテラルにはオプションの`character set introducer`と`COLLATE clause`あり、特定の文字セットと照合順序を使用する文字列として指定できます。
+文字列リテラルにはオプションの`character set introducer`と`COLLATE clause`があり、特定の文字セットと照合順序を使用する文字列として指定できます。
[_charset_name]'string' [COLLATE collation_name]
@@ -79,7 +79,7 @@ N'literal'（またはn'literal'）を使用して、各国語
## 日付と時刻のリテラル {#date-and-time-literals}
-日付と時刻のリテラル値は`'20170824'` `'2017-08-24'`いずれか`20170824`日付として解釈します。
+日付と時刻のリテラル値では、 `'20170824'` 、 `'2017-08-24'` 、 `20170824`のいずれかが日付として解釈されます。
TiDB は次の日付形式をサポートしています。
diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md
index fbb560e47031d..bfa44155920ae 100644
--- a/migrate-from-tidb-to-mysql.md
+++ b/migrate-from-tidb-to-mysql.md
@@ -44,7 +44,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する
tiup bench tpcc -H 127.0.0.1 -P 4000 -D tpcc --warehouses 4 run --time 300s
```
- `go-tpc`詳細については[TiDBでTPC-Cテストを実行する方法](/benchmark/benchmark-tidb-using-tpcc.md)を参照してください。
+ `go-tpc`の詳細については[TiDBでTPC-Cテストを実行する方法](/benchmark/benchmark-tidb-using-tpcc.md)を参照してください。
## ステップ2. 全データを移行する {#step-2-migrate-full-data}
diff --git a/non-transactional-dml.md b/non-transactional-dml.md
index e5ea8e7cf017f..dcef5f64c3947 100644
--- a/non-transactional-dml.md
+++ b/non-transactional-dml.md
@@ -181,7 +181,7 @@ SHOW PROCESSLIST;
非トランザクションDML文を終了するには、 `KILL TIDB `使用します。TiDBは現在実行中のバッチ以降のすべてのバッチをキャンセルします。実行結果はログから取得できます。
-`KILL TIDB`詳細については、参考文献[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。
+`KILL TIDB`の詳細については、参考文献[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。
### バッチ分割ステートメントをクエリする {#query-the-batch-dividing-statement}
diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md
index a2b0b9eb9fee0..b7856ddd24f39 100644
--- a/optimizer-fix-controls.md
+++ b/optimizer-fix-controls.md
@@ -16,7 +16,7 @@ summary: オプティマイザー修正制御機能について学習し、tidb_
v6.5.3 および v7.1.0 以降、TiDB は、オプティマイザーの動作をより細かく制御するための[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を提供します。
-各修正は、特定の目的のためにTiDBオプティマイザーの動作を調整するために用いられる制御項目です。修正には、動作変更の技術的な詳細が記載されたGitHub Issueに対応する番号が付けられています。例えば、修正`44262`場合、修正[問題44262](https://github.com/pingcap/tidb/issues/44262)でその制御内容を確認できます。
+各修正は、特定の目的のためにTiDBオプティマイザーの動作を調整するために用いられる制御項目です。修正には、動作変更の技術的な詳細が記載されたGitHub Issueに対応する番号が付けられています。例えば、修正`44262`の場合、修正[問題44262](https://github.com/pingcap/tidb/issues/44262)でその制御内容を確認できます。
システム変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 、複数の修正をカンマ区切りで 1 つの値として受け入れます ( `,` )。形式は`"<#issue1>:,<#issue2>:,...,<#issueN>:"`で、 `<#issueN>`修正番号です。例:
diff --git a/pd-configuration-file.md b/pd-configuration-file.md
index e8a823d8ac2cf..ff0ab4030a133 100644
--- a/pd-configuration-file.md
+++ b/pd-configuration-file.md
@@ -103,7 +103,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの
- etcdの`election-timeout`の設定項目に相当します。PDノードに組み込まれたetcdインスタンスの選出タイムアウトを制御します。etcdインスタンスがこの期間内に他のetcdインスタンスから有効なハートビートを受信しない場合、 Raft選出を開始します。
- デフォルト値: `3000ms`
-- この値は[`tick-interval`](#tick-interval)の5倍以上でなければなりません。例えば、 `tick-interval`が`500ms`場合、 `election-interval` `2500ms`以上でなければなりません。
+- この値は[`tick-interval`](#tick-interval)の5倍以上でなければなりません。例えば、 `tick-interval`が`500ms`の場合、 `election-interval`は`2500ms`以上でなければなりません。
### `enable-prevote` {#enable-prevote}
@@ -119,7 +119,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの
- PD が TSO の物理時間を更新する間隔。
- TSO物理時間のデフォルトの更新間隔では、PDは最大262144個のTSOを提供します。より多くのTSOを取得するには、この設定項目の値を減らしてください。最小値は`1ms`です。
-- この設定項目を減らすと、PDのCPU使用率が増加する可能性があります。テストによると、間隔が`50ms`の場合と比較して、間隔が`1ms`場合、PDの[CPU使用率](https://man7.org/linux/man-pages/man1/top.1.html)約10%増加します。
+- この設定項目を減らすと、PDのCPU使用率が増加する可能性があります。テストによると、間隔が`50ms`の場合と比較して、間隔が`1ms`の場合、PDの[CPU使用率](https://man7.org/linux/man-pages/man1/top.1.html)が約10%増加します。
- デフォルト値: `50ms`
- 最小値: `1ms`
diff --git a/pd-control.md b/pd-control.md
index 66fcba40da399..b504c63b57c69 100644
--- a/pd-control.md
+++ b/pd-control.md
@@ -1118,13 +1118,13 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope
>
> クラスター内のいずれかのコンポーネントが v5.2 より前の場合、 `query`ディメンションの設定は有効になりません。一部のコンポーネントを v5.2 以降にアップグレードした後も、スケジューラはデフォルトで`byte`および`key`ディメンションに基づいてホットスポット バランシングを優先します。クラスター内のすべてのコンポーネントを v5.2 以降にアップグレードした後も、このような設定は互換性のために引き続き有効になります。
>
- > v8.5.7 以降では、TiKV はホットリージョン スケジューリングのために読み取り CPU 使用率を報告します。読み取り CPU レポートをサポートするクラスターでは、デフォルトの`read-priorities`値は`cpu,byte`です。読み取り CPU レポートをサポートしないクラスターでは、PD は自動的に`query,byte`にフォールバックし、クラスターが`query`ディメンションもサポートしない場合は`byte,key`にフォールバックします。 `pd-ctl`を使用してリアルタイム設定を表示できます。通常、これらの設定を変更する必要はありません。
+ > v8.5.7 以降では、TiKV はホットリージョン スケジューリングのために読み取り CPU 使用率を報告します。読み取り CPU レポートをサポートするクラスターでは、デフォルトの`read-priorities`の値は`cpu,byte`です。読み取り CPU レポートをサポートしないクラスターでは、PD は自動的に`query,byte`にフォールバックし、クラスターが`query`ディメンションもサポートしない場合は`byte,key`にフォールバックします。 `pd-ctl`を使用してリアルタイム設定を表示できます。通常、これらの設定を変更する必要はありません。
```bash
scheduler config balance-hot-region-scheduler set read-priorities cpu,byte
```
-- `strict-picking-store`ホットリージョンスケジューリングの検索空間を制御します。通常は有効になっています。この設定項目は、 `rank-formula-version`が`v1`場合のみ動作に影響します。有効にすると、ホットリージョンスケジューリングは設定された2つのディメンションのホットリージョンバランスを確保します。無効にすると、ホットリージョンスケジューリングは優先度が最も高いディメンションのバランスのみを確保するため、他のディメンションのバランスが低下する可能性があります。通常、この設定を変更する必要はありません。
+- `strict-picking-store`はホットリージョンスケジューリングの検索空間を制御します。通常は有効になっています。この設定項目は、 `rank-formula-version`が`v1`の場合のみ動作に影響します。有効にすると、ホットリージョンスケジューリングは設定された2つのディメンションのホットリージョンバランスを確保します。無効にすると、ホットリージョンスケジューリングは優先度が最も高いディメンションのバランスのみを確保するため、他のディメンションのバランスが低下する可能性があります。通常、この設定を変更する必要はありません。
```bash
scheduler config balance-hot-region-scheduler set strict-picking-store true
diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md
index 16ac08d68c11a..15edc16612bda 100644
--- a/performance-tuning-methods.md
+++ b/performance-tuning-methods.md
@@ -404,7 +404,7 @@ TiDB はフェーズ`execute`で PD および TiKV と連携します。次の
TSO待機時間は`TSO WAIT`と記録され、TSO要求のネットワーク時間は`TSO RPC`と記録されます。TSO待機が完了すると、TiDBエグゼキューターは通常、TiKVに読み取りまたは書き込み要求を送信します。
- 一般的な KV 読み取り要求: `Get` `BatchGet`および`Cop`
-- 一般的`Commit` KV書き込み要求: 2フェーズコミット`Prewrite`場合は`PessimisticLock`
+- 一般的な KV 書き込み要求: 2フェーズコミットの`PessimisticLock` `Prewrite`および`Commit`
diff --git a/pipelined-dml.md b/pipelined-dml.md
index 16e0166352922..97b43f22cc78a 100644
--- a/pipelined-dml.md
+++ b/pipelined-dml.md
@@ -90,7 +90,7 @@ DML ステートメントを実行した後、 [`tidb_last_txn_info`](/system-va
SELECT @@tidb_last_txn_info;
```
-出力の`pipelined`フィールドが`true`場合、パイプライン DML が正常に使用されていることを示します。
+出力の`pipelined`フィールドが`true`の場合、パイプライン DML が正常に使用されていることを示します。
## ベストプラクティス {#best-practices}
diff --git a/releases/release-2.0.10.md b/releases/release-2.0.10.md
index 85b889fbdccf6..9cc70567a840c 100644
--- a/releases/release-2.0.10.md
+++ b/releases/release-2.0.10.md
@@ -13,9 +13,9 @@ summary: TiDB 2.0.10およびTiDB Ansible 2.0.10は、2018年12月18日にリリ
- `ORDER BY`と`UNION`句でテーブル名を含む列を引用符で囲めない問題を修正[＃8514](https://github.com/pingcap/tidb/pull/8514)
- `UNCOMPRESS`関数が不正な入力長を判断しない問題を修正 [＃8607](https://github.com/pingcap/tidb/pull/8607)
- TiDB アップグレード時に`ANSI_QUOTES SQL_MODE`で発生した問題を修正 [＃8575](https://github.com/pingcap/tidb/pull/8575)
-- `select`場合によっては間違った結果が返される問題を修正[＃8570](https://github.com/pingcap/tidb/pull/8570)
+- `select`で場合によっては間違った結果が返される問題を修正[＃8570](https://github.com/pingcap/tidb/pull/8570)
- 終了信号を受信してもTiDBが終了できない可能性がある問題を修正しました [＃8501](https://github.com/pingcap/tidb/pull/8501)
-- `IndexLookUpJoin`場合によっては間違った結果が返される問題を修正[＃8508](https://github.com/pingcap/tidb/pull/8508)
+- `IndexLookUpJoin`で場合によっては間違った結果が返される問題を修正[＃8508](https://github.com/pingcap/tidb/pull/8508)
- `GetVar`または`SetVar` を含むフィルターをプッシュダウンしない [＃8454](https://github.com/pingcap/tidb/pull/8454)
- `UNION`集合演算子の結果の長さが場合によっては正しくない問題を修正[＃8491](https://github.com/pingcap/tidb/pull/8491)
- `PREPARE FROM @var_name` の問題を修正 [＃8488](https://github.com/pingcap/tidb/pull/8488)
diff --git a/releases/release-2.0.9.md b/releases/release-2.0.9.md
index 05556705c21c4..82bab5b6e1c24 100644
--- a/releases/release-2.0.9.md
+++ b/releases/release-2.0.9.md
@@ -18,7 +18,7 @@ summary: TiDB 2.0.9は2018年11月19日にリリースされ、システムの
- `TRUNCATE`組み込み関数が符号なし整数型のパラメータをサポートするようにする [＃8069](https://github.com/pingcap/tidb/pull/8069)
- 一部のケースにおける統計モジュールの主キーの選択性推定の問題を修正[＃8150](https://github.com/pingcap/tidb/pull/8150)
- `Session`変数を追加して、 `_tidb_rowid` に書き込むことができるかどうかを制御します。 [＃8126](https://github.com/pingcap/tidb/pull/8126)
-- `PhysicalProjection`場合によってはpanic問題を修正[＃8154](https://github.com/pingcap/tidb/pull/8154)
+- `PhysicalProjection`で場合によってはpanic問題を修正[＃8154](https://github.com/pingcap/tidb/pull/8154)
- いくつかのケースで`Union`文の不安定な結果を修正[＃8168](https://github.com/pingcap/tidb/pull/8168)
- `Insert`以外の文で`NULL`が`values`を返さない問題を修正 [＃8179](https://github.com/pingcap/tidb/pull/8179)
- 統計モジュールが古いデータをクリアできないことがある問題を修正[＃8184](https://github.com/pingcap/tidb/pull/8184)
diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md
index 7db1dd708492c..79cf2f60787ae 100644
--- a/releases/release-2.1-beta.md
+++ b/releases/release-2.1-beta.md
@@ -61,7 +61,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ
- ネットワーク分離後にネットワークが回復したときにリーダーの再選出を回避するために、PDノード間でRaft PreVoteを有効にする
- Balance Scheduler が小さなリージョンを頻繁にスケジュールする問題を最適化します。
- ホットスポットスケジューラを最適化し、トラフィック統計情報のジッタに対する適応性を向上させます。
-- スケジュール`region merge`ときに行数の多い領域をスキップする
+- `region merge`をスケジュールするときに行数の多い領域をスキップする
- スケジュール中にマシン障害によってデータが利用できなくなるリスクを軽減するために、デフォルトで`raft learner`有効にします。
- `pd-recover`から`max-replica`取り除く
- `Filter`指標を追加
diff --git a/releases/release-2.1-rc.4.md b/releases/release-2.1-rc.4.md
index d7541182e2900..0c987103f2534 100644
--- a/releases/release-2.1-rc.4.md
+++ b/releases/release-2.1-rc.4.md
@@ -33,7 +33,7 @@ summary: TiDB 2.1 RC4は2018年10月23日にリリースされ、安定性、SQL
- クエリが空の場合、 `SHOW PROCESSLIST`結果の`Command`フィールドを`Sleep`に設定します[＃7839](https://github.com/pingcap/tidb/pull/7839)
- 表現
- `SYSDATE`関数の定数の折り畳みの問題を修正 [＃7895](https://github.com/pingcap/tidb/pull/7895)
- - `SUBSTRING_INDEX`場合によってはパニックになる問題を修正[＃7897](https://github.com/pingcap/tidb/pull/7897)
+ - `SUBSTRING_INDEX`が場合によってはパニックになる問題を修正[＃7897](https://github.com/pingcap/tidb/pull/7897)
- DDL
- `invalid ddl job type`エラースローすることによって発生するスタックオーバーフローの問題を修正しました [＃7958](https://github.com/pingcap/tidb/pull/7958)
- `ADMIN CHECK TABLE`の結果が場合によっては正しくない問題を修正[＃7975](https://github.com/pingcap/tidb/pull/7975)
diff --git a/releases/release-2.1-rc.5.md b/releases/release-2.1-rc.5.md
index d2f503009c26d..55c51d2ea243b 100644
--- a/releases/release-2.1-rc.5.md
+++ b/releases/release-2.1-rc.5.md
@@ -12,7 +12,7 @@ summary: TiDB 2.1 RC5は2018年11月12日にリリースされ、安定性、SQL
## TiDB {#tidb}
- SQLオプティマイザー
- - `IndexReader`場合によっては間違ったハンドルを読み取る問題を修正[＃8132](https://github.com/pingcap/tidb/pull/8132)
+ - `IndexReader`が場合によっては間違ったハンドルを読み取る問題を修正[＃8132](https://github.com/pingcap/tidb/pull/8132)
- `IndexScan Prepared`文で`Plan Cache` を使用しているときに発生する問題を修正 [＃8055](https://github.com/pingcap/tidb/pull/8055)
- `Union`文の結果が不安定になる問題を修正[＃8165](https://github.com/pingcap/tidb/pull/8165)
- SQL実行エンジン
@@ -52,7 +52,7 @@ summary: TiDB 2.1 RC5は2018年11月12日にリリースされ、安定性、SQL
- [＃1308](https://github.com/pingcap/pd/pull/1308)
- `regions/check` APIが間違った結果を返す問題を修正[＃1311](https://github.com/pingcap/pd/pull/1311)
- PD参加失敗後にPDが参加を再開できない問題を修正[＃1279](https://github.com/pingcap/pd/pull/1279)
-- `watch leader`場合によってはイベントが失われる可能性がある問題を修正[＃1317](https://github.com/pingcap/pd/pull/1317)
+- `watch leader`で場合によってはイベントが失われる可能性がある問題を修正[＃1317](https://github.com/pingcap/pd/pull/1317)
## TiKV {#tikv}
diff --git a/releases/release-2.1.2.md b/releases/release-2.1.2.md
index 7f6a5489de3d1..d636a465d51e5 100644
--- a/releases/release-2.1.2.md
+++ b/releases/release-2.1.2.md
@@ -13,7 +13,7 @@ summary: TiDB 2.1.2およびTiDB Ansible 2.1.2は、2018年12月22日にリリ
- ローリングアップデートにおけるTiDBの終了メカニズムの改善 [＃8707](https://github.com/pingcap/tidb/pull/8707)
- 生成された列にインデックスを追加することで発生するpanic問題を修正[＃8676](https://github.com/pingcap/tidb/pull/8676)
- 一部のケースでSQL文に`TIDB_SMJ Hint`存在する場合にオプティマイザが最適なクエリプランを見つけられない問題を修正[＃8729](https://github.com/pingcap/tidb/pull/8729)
-- `AntiSemiJoin`場合によっては誤った結果が返される問題を修正[＃8730](https://github.com/pingcap/tidb/pull/8730)
+- `AntiSemiJoin`で場合によっては誤った結果が返される問題を修正[＃8730](https://github.com/pingcap/tidb/pull/8730)
- `utf8`文字セットの有効文字チェックの改善 [＃8754](https://github.com/pingcap/tidb/pull/8754)
- トランザクションで読み取り操作の前に書き込み操作を実行すると、時間型のフィールドが誤った結果を返す可能性がある問題を修正しました。 [＃8746](https://github.com/pingcap/tidb/pull/8746)
diff --git a/releases/release-2.1.3.md b/releases/release-2.1.3.md
index 4dc700cfcea20..627d650ac7ce9 100644
--- a/releases/release-2.1.3.md
+++ b/releases/release-2.1.3.md
@@ -19,7 +19,7 @@ summary: TiDB 2.1.3 および TiDB Ansible 2.1.3 がリリースされ、シス
- `CAST(AS TIME)`精度が大きすぎる場合はエラーを返す[＃9058](https://github.com/pingcap/tidb/pull/9058)
- 直積で`Sort Merge Join`使用を許可する [＃9037](https://github.com/pingcap/tidb/pull/9037)
- 一部のケースで統計ワーカーがpanic後に再開できない問題を修正[＃9085](https://github.com/pingcap/tidb/pull/9085)
- - `Sort Merge Join`場合によっては間違った結果が返される問題を修正[＃9046](https://github.com/pingcap/tidb/pull/9046)
+ - `Sort Merge Join`で場合によっては間違った結果が返される問題を修正[＃9046](https://github.com/pingcap/tidb/pull/9046)
- `CASE`節で JSON 型を返すことをサポート [＃8355](https://github.com/pingcap/tidb/pull/8355)
- サーバ
- コメントに非TiDBヒントが存在する場合、エラーではなく警告を返します。 [＃8766](https://github.com/pingcap/tidb/pull/8766)
diff --git a/releases/release-2.1.5.md b/releases/release-2.1.5.md
index 7e296edf42396..e43592299baff 100644
--- a/releases/release-2.1.5.md
+++ b/releases/release-2.1.5.md
@@ -27,7 +27,7 @@ summary: TiDB 2.1.5とTiDB Ansible 2.1.5は、2019年2月28日にリリースさ
- `tidb_force_priority`システム変数の値が設定ファイルに設定されている値と異なる問題を修正しました [＃9347](https://github.com/pingcap/tidb/pull/9347)
- 一般ログに`current_db`フィールドを追加して、現在使用されているデータベースの名前を出力します。 [＃9346](https://github.com/pingcap/tidb/pull/9346)
- テーブルID のテーブル情報を取得するHTTP APIを追加します。 [＃9408](https://github.com/pingcap/tidb/pull/9408)
- - `LOAD DATA`場合によっては誤ったデータを読み込む問題を修正[＃9414](https://github.com/pingcap/tidb/pull/9414)
+ - `LOAD DATA`が場合によっては誤ったデータを読み込む問題を修正[＃9414](https://github.com/pingcap/tidb/pull/9414)
- MySQLクライアントとTiDB間の接続構築に時間がかかる場合がある問題を修正[＃9451](https://github.com/pingcap/tidb/pull/9451)
- DDL
- `DROP COLUMN`操作をキャンセルする際のいくつかの問題を修正 [＃9352](https://github.com/pingcap/tidb/pull/9352)
diff --git a/releases/release-2.1.8.md b/releases/release-2.1.8.md
index ee6e303aa9719..8a55dd28b528f 100644
--- a/releases/release-2.1.8.md
+++ b/releases/release-2.1.8.md
@@ -31,7 +31,7 @@ TiDB Ansible バージョン: 2.1.8
- `time_zone` の値を検証する [＃10000](https://github.com/pingcap/tidb/pull/10000)
- `2019.01.01`回限りのフォーマットサポート [＃10001](https://github.com/pingcap/tidb/pull/10001)
- `EXPLAIN`文によって返される結果で行数の推定値が正しく表示されない場合がある問題を修正[＃10044](https://github.com/pingcap/tidb/pull/10044)
-- `KILL TIDB [session id]`場合によっては文の実行を即座に停止できない問題を修正[＃9976](https://github.com/pingcap/tidb/pull/9976)
+- `KILL TIDB [session id]`が場合によっては文の実行を即座に停止できない問題を修正[＃9976](https://github.com/pingcap/tidb/pull/9976)
- いくつかのケースにおける定数フィルタリング条件の述語プッシュダウンの問題を修正[＃10049](https://github.com/pingcap/tidb/pull/10049)
- 読み取り専用ステートメントが一部のケースで正しく処理されない問題を修正[＃10048](https://github.com/pingcap/tidb/pull/10048)
diff --git a/releases/release-2.1.9.md b/releases/release-2.1.9.md
index 0d05d8d29e59e..776567c55930c 100644
--- a/releases/release-2.1.9.md
+++ b/releases/release-2.1.9.md
@@ -52,7 +52,7 @@ TiDB Ansible バージョン: 2.1.9
- TiDB Binlog
- 主キー列のunsigned int型のデータがマイナスであるため、データレプリケーションが中断される問題を修正しました。 [＃574](https://github.com/pingcap/tidb-binlog/pull/574)
- - ダウンストリームが`pb`場合に圧縮オプションを削除し、ダウンストリーム名を`pb`から`file`に変更します[＃597](https://github.com/pingcap/tidb-binlog/pull/575)
+ - ダウンストリームが`pb`の場合に圧縮オプションを削除し、ダウンストリーム名を`pb`から`file`に変更します[＃597](https://github.com/pingcap/tidb-binlog/pull/575)
- 2.1.7で導入されたReparoが間違った`UPDATE`ステートメントを生成するバグを修正しました [＃576](https://github.com/pingcap/tidb-binlog/pull/576)
- TiDB Lightning
- 列データのビット型がパーサーによって誤って解析されるバグを修正 [＃164](https://github.com/pingcap/tidb-lightning/pull/164)
diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md
index 5983b6c1735eb..15a159f5809c3 100644
--- a/releases/release-3.0.0-rc.1.md
+++ b/releases/release-3.0.0-rc.1.md
@@ -111,7 +111,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1
- TiDB Binlog
- unsigned int 型の主キー列のbinlogデータが負の場合にレプリケーションが中止される問題を修正しました。 [＃573](https://github.com/pingcap/tidb-binlog/pull/573)
- - ダウンストリームが`pb`場合は圧縮オプションを提供しません。ダウンストリーム名を`pb`から`file`に変更します[＃559](https://github.com/pingcap/tidb-binlog/pull/559)
+ - ダウンストリームが`pb`の場合は圧縮オプションを提供しません。ダウンストリーム名を`pb`から`file`に変更します[＃559](https://github.com/pingcap/tidb-binlog/pull/559)
- Pumpにローカルストレージへの非同期フラッシュを許可する`storage.sync-log`設定項目を追加する [＃509](https://github.com/pingcap/tidb-binlog/pull/509)
- PumpとDrainer間の通信のトラフィック圧縮をサポート [＃495](https://github.com/pingcap/tidb-binlog/pull/495)
- 異なるSQLモードでのDDLクエリの解析をサポートするために、 Drainerに`syncer.sql-mode`構成項目を追加します。 [＃511](https://github.com/pingcap/tidb-binlog/pull/511)
diff --git a/releases/release-3.0.1.md b/releases/release-3.0.1.md
index 570667b193cc1..120f9520a9a3c 100644
--- a/releases/release-3.0.1.md
+++ b/releases/release-3.0.1.md
@@ -29,7 +29,7 @@ TiDB Ansible バージョン: 3.0.1
- ポイントクエリ中に列が複数回クエリされ、返された結果が NULL である場合に発生するpanic問題を修正しました[＃11226](https://github.com/pingcap/tidb/pull/11226)
- `RAND`関数使用する際に非スレッドセーフ`rand.Rand`によって発生するデータ競合問題を修正 [＃11169](https://github.com/pingcap/tidb/pull/11169)
- `oom-action="cancel"`が設定されている場合、SQL 文のメモリ使用量がしきい値を超えているにもかかわらず、この文の実行がキャンセルされず、返される結果が正しくないというバグを修正しました[＃11004](https://github.com/pingcap/tidb/pull/11004)
-- MemTracker `SHOW PROCESSLIST`メモリ使用量が正しく消去されなかったため、メモリ使用量が`0`ではないと表示される問題を修正しました[＃10970](https://github.com/pingcap/tidb/pull/10970)
+- MemTrackerのメモリ使用量が正しく消去されなかったため、 `SHOW PROCESSLIST`でメモリ使用量が`0`ではないと表示される問題を修正しました[＃10970](https://github.com/pingcap/tidb/pull/10970)
- 整数と非整数の比較結果が場合によっては正しくないというバグを修正[＃11194](https://github.com/pingcap/tidb/pull/11194)
- テーブルパーティションのクエリに明示的なトランザクションの述語が含まれている場合にクエリ結果が正しくないというバグを修正しました[＃11196](https://github.com/pingcap/tidb/pull/11196)
- `infoHandle` `NULL` になる可能性があるため、DDL ジョブのpanic問題を修正しました。 [＃11022](https://github.com/pingcap/tidb/pull/11022)
diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md
index d3bb7ea323b64..65a9ad5ca3aac 100644
--- a/releases/release-3.0.2.md
+++ b/releases/release-3.0.2.md
@@ -89,7 +89,7 @@ TiDB Ansible バージョン: 3.0.2
- `SPLIT TABLE … REGIONS/INDEX`で返された結果を追加し、 `TOTAL_SPLIT_REGION`と`SCATTER_FINISH_RATIO`に、結果のタイムアウト前に正常に分割されたリージョンの数を表示するようにします。 [＃11484](https://github.com/pingcap/tidb/pull/11484)
- 列属性が`ON UPDATE CURRENT_TIMESTAMP`で浮動小数点精度が指定されている場合、 `SHOW CREATE TABLE`ようなステートメントで表示される精度が不完全になる問題を修正しました[＃11591](https://github.com/pingcap/tidb/pull/11591)
- 仮想生成列の式に別の仮想生成列が含まれている場合、列のインデックス結果が正しく計算されない問題を修正しました。 [＃11475](https://github.com/pingcap/tidb/pull/11475)
- - `ALTER TABLE … ADD PARTITION …`文の`VALUE LESS THAN`後にマイナス記号を追加できない問題を修正 [＃11581](https://github.com/pingcap/tidb/pull/11581)
+ - `ALTER TABLE … ADD PARTITION …`文の`VALUE LESS THAN`の後にマイナス記号を追加できない問題を修正 [＃11581](https://github.com/pingcap/tidb/pull/11581)
- モニター
- `TiKVTxnCmdCounter`監視メトリックが登録されていないため、データが収集および報告されない問題を修正しました[＃11316](https://github.com/pingcap/tidb/pull/11316)
- Bind Info の`BindUsageCounter` `BindTotalGauge`監視メトリックを追加します`BindMemoryUsage` [＃11467](https://github.com/pingcap/tidb/pull/11467)
diff --git a/releases/release-4.0.5.md b/releases/release-4.0.5.md
index 1205ab48e16e2..f9f63d70d1092 100644
--- a/releases/release-4.0.5.md
+++ b/releases/release-4.0.5.md
@@ -124,7 +124,7 @@ TiDB バージョン: 4.0.5
- `BatchPointGet` の誤った使用法によって生じた誤った結果を修正 [＃19456](https://github.com/pingcap/tidb/pull/19456)
- `UnionScan` `Apply`演算子の内側にある場合に発生する誤った結果を修正します。 [＃19496](https://github.com/pingcap/tidb/pull/19496)
- `EXECUTE`文を使用して負荷の高いクエリログを出力することで発生するpanicを修正 [＃17419](https://github.com/pingcap/tidb/pull/17419)
- - 結合キーが`ENUM`または`SET`場合のインデックス結合エラーを修正しました[＃19235](https://github.com/pingcap/tidb/pull/19235)
+ - 結合キーが`ENUM`または`SET`の場合のインデックス結合エラーを修正しました[＃19235](https://github.com/pingcap/tidb/pull/19235)
- インデックス列に`NULL`値が存在する場合にクエリ範囲を構築できない問題を修正しました [＃19358](https://github.com/pingcap/tidb/pull/19358)
- グローバル構成の更新によって発生するデータ競合の問題を修正[＃17964](https://github.com/pingcap/tidb/pull/17964)
- 大文字スキーマで文字セットを変更するときに発生するpanic問題を修正 [＃19286](https://github.com/pingcap/tidb/pull/19286)
diff --git a/releases/release-4.0.6.md b/releases/release-4.0.6.md
index 79967852873f9..399ba3d025057 100644
--- a/releases/release-4.0.6.md
+++ b/releases/release-4.0.6.md
@@ -169,8 +169,8 @@ TiDB バージョン: 4.0.6
- テーブルのレプリケーションステータスの計算によって発生するクラッシュを修正
- ユーザーがサポートされていないDDL操作を適用した後に、 TiFlashがデータ読み取りに使用できなくなる問題を修正しました。
- `utf8mb4_bin`として扱われるサポートされていない照合によって発生する例外を修正しました
- - TiFlashコプロセッサエグゼキュータのQPSパネルがGrafanaで常に`0`表示される問題を修正
- - 入力が`NULL`場合の`FROM_UNIXTIME`関数の誤った結果を修正
+ - TiFlashコプロセッサエグゼキュータのQPSパネルがGrafanaで常に`0`が表示される問題を修正
+ - 入力が`NULL`の場合の`FROM_UNIXTIME`関数の誤った結果を修正
- ツール
diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md
index 62bc611b6fa48..0dfe8d689826e 100644
--- a/releases/release-5.0.0.md
+++ b/releases/release-5.0.0.md
@@ -60,7 +60,7 @@ TiDB バージョン: 5.0.0
- `INT_ONLY` : デフォルト値。動作はv5.0以前と同じです。 `alter-primary-key = false`と併せて、INT型のクラスター化インデックスを有効にするかどうかを制御できます。
> **Note:**
>
- > 5.0 GA の`INT_ONLY`の`tidb_enable_clustered_index`値は、5.0 RC の`OFF`値と同じ意味です。 `OFF`設定の 5.0 RC クラスターから 5.0 GA にアップグレードすると、 `INT_ONLY`と表示されます。
+ > 5.0 GA の`tidb_enable_clustered_index`の`INT_ONLY`値は、5.0 RC の`OFF`値と同じ意味です。 `OFF`設定の 5.0 RC クラスターから 5.0 GA にアップグレードすると、 `INT_ONLY`と表示されます。
### コンフィグレーションファイルパラメータ {#configuration-file-parameters}
diff --git a/releases/release-5.0.2.md b/releases/release-5.0.2.md
index 59bde0b0a0672..4752a24bfc1ef 100644
--- a/releases/release-5.0.2.md
+++ b/releases/release-5.0.2.md
@@ -66,7 +66,7 @@ TiDB バージョン: 5.0.2
- 一部のケースでプレフィックスインデックスとインデックス結合を使用することで発生するpanic問題を修正[＃24547](https://github.com/pingcap/tidb/issues/24547) [＃24716](https://github.com/pingcap/tidb/issues/24716) [＃24717](https://github.com/pingcap/tidb/issues/24717)
- `point get`のプリペアドプランキャッシュがトランザクションの`point get`文によって誤って使用される問題を修正しました[＃24741](https://github.com/pingcap/tidb/issues/24741)。
- - 照合順序が`ascii_bin`または`latin1_bin`場合に間違ったプレフィックスインデックス値を書き込む問題を修正しました[＃24569](https://github.com/pingcap/tidb/issues/24569)
+ - 照合順序が`ascii_bin`または`latin1_bin`の場合に間違ったプレフィックスインデックス値を書き込む問題を修正しました[＃24569](https://github.com/pingcap/tidb/issues/24569)
- GCワーカー[＃24591](https://github.com/pingcap/tidb/issues/24591)によって進行中のトランザクションが中断される可能性がある問題を修正
- `new-collation`が有効で`new-row-format`無効の場合、クラスター化インデックスでポイントクエリが間違って実行される可能性があるバグを修正しました[＃24541](https://github.com/pingcap/tidb/issues/24541)
- シャッフルハッシュ結合[＃24490](https://github.com/pingcap/tidb/pull/24490)パーティションキーの変換をリファクタリングする
@@ -84,7 +84,7 @@ TiDB バージョン: 5.0.2
- TiKV
- 古い値の読み取りによって引き起こされる TiCDC OOM 問題を修正[＃9996](https://github.com/tikv/tikv/issues/9996) [＃9981](https://github.com/tikv/tikv/issues/9981)
- - 照合順序が`latin1_bin` [＃24548](https://github.com/pingcap/tidb/issues/24548)場合にクラスター化主キー列のセカンダリインデックスに空の値が含まれる問題を修正しました
+ - 照合順序が`latin1_bin`の場合にクラスター化主キー列のセカンダリインデックスに空の値が含まれる問題を修正しました[＃24548](https://github.com/pingcap/tidb/issues/24548)
- `abort-on-panic`設定を追加すると、panic発生時にTiKVがコアダンプファイルを生成できるようになります。コアダンプ[＃10216](https://github.com/tikv/tikv/pull/10216)を有効にするには、ユーザーは環境を正しく設定する必要があります。
- TiKVがビジーでないときに発生する`point get`クエリのパフォーマンス回帰の問題を修正しました[＃10046](https://github.com/tikv/tikv/issues/10046)
diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md
index a959b67463faa..eadffe6ea1da3 100644
--- a/releases/release-5.3.0.md
+++ b/releases/release-5.3.0.md
@@ -46,8 +46,8 @@ v5.3 の主な新機能または改善点は次のとおりです。
| TiKV | [`storage.reserve-space`](/tikv-configuration-file.md#reserve-space) | 変更 | TiKV起動時にディスク保護のために予約される領域を制御します。v5.3.0以降では、予約領域の80%がディスク容量不足時の運用・保守に必要な追加ディスク領域として使用され、残りの20%は一時ファイルの保存に使用されます。 |
| TiKV | `memory-usage-limit` | 変更 | この構成項目は TiDB v5.3.0 で新しく追加され、その値はストレージの.block-cache.capacity に基づいて計算されます。 |
| TiKV | [`raftstore.store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530) | 新しく追加された | Raft I/Oタスクを処理するスレッドの許容数。これはStoreWriterスレッドプールのサイズです。このスレッドプールのサイズを変更する場合は、 [TiKV スレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 |
-| TiKV | [`raftstore.raft-write-size-limit`](/tikv-configuration-file.md#raft-write-size-limit-new-in-v530) | 新しく追加された | Raftデータがディスクに書き込まれるしきい値を決定します。データサイズがこの設定項目の値より大きい場合、データはディスクに書き込まれます。1の値が`raftstore.store-io-pool-size` `0`場合、この設定項目は有効になりません。 |
-| TiKV | `raftstore.raft-msg-flush-interval` | 新しく追加された | Raftメッセージをバッチ送信する間隔を指定します。バッチ送信されたRaftメッセージは、この設定項目で指定された間隔ごとに送信されます。1の値が`raftstore.store-io-pool-size` `0`場合、この設定項目は無効になります。 |
+| TiKV | [`raftstore.raft-write-size-limit`](/tikv-configuration-file.md#raft-write-size-limit-new-in-v530) | 新しく追加された | Raftデータがディスクに書き込まれるしきい値を決定します。データサイズがこの設定項目の値より大きい場合、データはディスクに書き込まれます。`raftstore.store-io-pool-size`の値が`0`の場合、この設定項目は有効になりません。 |
+| TiKV | `raftstore.raft-msg-flush-interval` | 新しく追加された | Raftメッセージをバッチ送信する間隔を指定します。バッチ送信されたRaftメッセージは、この設定項目で指定された間隔ごとに送信されます。`raftstore.store-io-pool-size`の値が`0`の場合、この設定項目は無効になります。 |
| TiKV | `raftstore.raft-reject-transfer-leader-duration` | 削除済み | Leaderが新しく追加されたノードに転送される最小期間を決定します。 |
| PD | [`log.file.max-days`](/pd-configuration-file.md#max-days) | 変更 | ログを保持する最大日数を制御します。デフォルト値は`1`から`0`に変更されます。 |
| PD | [`log.file.max-backups`](/pd-configuration-file.md#max-backups) | 変更 | 保持されるログの最大数を制御します。デフォルト値は`7`から`0`に変更されます。 |
@@ -270,7 +270,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機
- コプロセッサがロックに遭遇したときに影響を受けるSQL文をデバッグログに表示します。これは問題の診断に役立ちます[＃27718](https://github.com/pingcap/tidb/issues/27718)
- SQL論理レイヤーでデータをバックアップおよび復元するときに、バックアップおよび復元データのサイズを表示する機能をサポート [＃27247](https://github.com/pingcap/tidb/issues/27247)
- - `tidb_analyze_version`が`2`場合の ANALYZE のデフォルトのコレクション ロジックを改善し、コレクションを高速化し、リソースのオーバーヘッドを削減します。
+ - `tidb_analyze_version`が`2`の場合の ANALYZE のデフォルトのコレクション ロジックを改善し、コレクションを高速化し、リソースのオーバーヘッドを削減します。
- `ANALYZE TABLE table_name COLUMNS col_1, col_2, ... , col_n`構文を導入します。この構文を使用すると、幅の広いテーブル内の一部の列のみの統計情報を収集できるため、統計収集の速度が向上します。
- TiKV
diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md
index 96fb5d3aecd93..b5828ac0a258a 100644
--- a/releases/release-5.4.3.md
+++ b/releases/release-5.4.3.md
@@ -85,7 +85,7 @@ TiDB バージョン: 5.4.3
- DB Conn [＃3733](https://github.com/pingcap/tiflow/issues/3733)取得する際に DM ワーカーがスタックする可能性がある問題を修正しました
- DMが`Specified key was too long`エラーを報告する問題を修正しました[＃5315](https://github.com/pingcap/tiflow/issues/5315)
- - レプリケーション[＃7028](https://github.com/pingcap/tiflow/issues/7028)中にlatin1データが破損する可能性がある問題を修正
+ - レプリケーション中にlatin1データが破損する可能性がある問題を修正[＃7028](https://github.com/pingcap/tiflow/issues/7028)
- TiDBがIPv6ホスト[＃6249](https://github.com/pingcap/tiflow/issues/6249)を使用しているときにDMが起動に失敗する問題を修正
- `query-status` [＃4811](https://github.com/pingcap/tiflow/issues/4811)で起こりうるデータ競合の問題を修正
- リレーがエラー[＃6193](https://github.com/pingcap/tiflow/issues/6193)に遭遇したときの goroutine リークを修正
diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md
index 7de6b5183e90a..2836fb0eb1502 100644
--- a/releases/release-6.0.0-dmr.md
+++ b/releases/release-6.0.0-dmr.md
@@ -305,7 +305,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。
- `INFORMATION_SCHEMA`テーブルから`TIDB_DIRECT_PLACEMENT`列を削除します。
- SQL プラン管理 (SPM) バインディングの`status`値が変更されます。
- `using`を削除します。
- - `using`代わりに`enabled` (使用可能) を追加します。
+ - `using`の代わりに`enabled` (使用可能) を追加します。
- `disabled`を追加します (利用不可)。
- DMはOpenAPIインターフェースを変更する
- 内部メカニズムの変更により、タスク管理関連のインターフェースは以前の実験的版との互換性がありません。適応には新しいバージョン[DM OpenAPIドキュメント](/dm/dm-open-api.md)を参照してください。
@@ -445,7 +445,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。
- 動的パーティションプルーニングモードでサブSELECT LIMITが期待どおりに動作しないバグを修正しました [＃32516](https://github.com/pingcap/tidb/issues/32516)
- `INFORMATION_SCHEMA.COLUMNS`表のビットデフォルト値の形式が間違っている、または一貫性がない問題を修正しました。 [＃32655](https://github.com/pingcap/tidb/issues/32655)
- サーバーの再起動後にパーティションテーブルの一覧表示でパーティションテーブルのプルーニングが機能しない可能性があるバグを修正[＃32416](https://github.com/pingcap/tidb/issues/32416)
- - `SET timestamp` `add column`後に間違ったデフォルトのタイムスタンプが使用される可能性があるバグを修正[＃31968](https://github.com/pingcap/tidb/issues/31968)
+ - `SET timestamp`の後に`add column`で間違ったデフォルトのタイムスタンプが使用される可能性があるバグを修正[＃31968](https://github.com/pingcap/tidb/issues/31968)
- MySQL 5.5 または 5.6 クライアントから TiDB パスワードなしアカウントへの接続が失敗する可能性があるバグを修正[＃32334](https://github.com/pingcap/tidb/issues/32334)
- トランザクションで動的モードでパーティション テーブルを読み取るときに誤った結果が発生する問題を修正しました。 [＃29851](https://github.com/pingcap/tidb/issues/29851)
- TiDBが重複したタスクをTiFlash にディスパッチする可能性があるバグを修正しました [＃32814](https://github.com/pingcap/tidb/issues/32814)
diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md
index 6be04e891e954..e65f2372ce450 100644
--- a/releases/release-6.1.0.md
+++ b/releases/release-6.1.0.md
@@ -297,7 +297,7 @@ TiDB バージョン: 6.1.0
新しいクラスターでは、 プリペアドプランキャッシュがデフォルトで有効化され、リクエストの`Prepare` `Execute`実行プランをキャッシュします。以降の実行では、クエリプランの最適化をスキップできるため、パフォーマンスが向上します。アップグレードされたクラスターは、設定ファイルから設定を継承します。新しいクラスターは新しいデフォルト値を使用するため、 プリペアドプランキャッシュ はデフォルトで有効化され、各セッションで最大100プランをキャッシュできます ( `capacity=100` )。この機能のメモリ消費量については、 [プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache)参照してください。
-- TiDB v6.1.0より前のバージョンでは、 `SHOW ANALYZE STATUS`インスタンスレベルのタスクを示し、タスクレコードはTiDBの再起動後に消去されます。TiDB v6.1.0以降では、 `SHOW ANALYZE STATUS`クラスタレベルのタスクを示し、タスクレコードは再起動後も保持されます。`tidb_analyze_version = 2`場合、 `Job_info`列に`analyze option`情報が追加されます。
+- TiDB v6.1.0より前のバージョンでは、 `SHOW ANALYZE STATUS`インスタンスレベルのタスクを示し、タスクレコードはTiDBの再起動後に消去されます。TiDB v6.1.0以降では、 `SHOW ANALYZE STATUS`クラスタレベルのタスクを示し、タスクレコードは再起動後も保持されます。`tidb_analyze_version = 2`の場合、 `Job_info`列に`analyze option`情報が追加されます。
- TiKV内のSSTファイルが破損すると、TiKVプロセスがpanicになる可能性があります。TiDB v6.1.0より前では、SSTファイルが破損するとTiKVは直ちにpanic状態になりました。TiDB v6.1.0以降では、SSTファイルが破損してから1時間後にTiKVプロセスがpanicになります。
diff --git a/releases/release-6.1.7.md b/releases/release-6.1.7.md
index 4a5bedc6afb98..fff5ba1ade804 100644
--- a/releases/release-6.1.7.md
+++ b/releases/release-6.1.7.md
@@ -83,7 +83,7 @@ TiDB バージョン: 6.1.7
- Backup & Restore (BR)
- - `resolved lock timeout`場合によっては誤って報告される問題を修正[＃43236](https://github.com/pingcap/tidb/issues/43236) @ [YuJuncen](https://github.com/YuJuncen)
+ - `resolved lock timeout`が場合によっては誤って報告される問題を修正[＃43236](https://github.com/pingcap/tidb/issues/43236) @ [YuJuncen](https://github.com/YuJuncen)
- クラスターで TiKV ノードがクラッシュしたときにバックアップ速度が低下する問題を修正しました [＃42973](https://github.com/pingcap/tidb/issues/42973) @ [YuJuncen](https://github.com/YuJuncen)
- TiCDC
diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md
index ab85e9562dd24..d40f99482f287 100644
--- a/releases/release-6.5.3.md
+++ b/releases/release-6.5.3.md
@@ -67,7 +67,7 @@ TiDB バージョン: 6.5.3
- パーティションテーブルのパーティションを切り捨てるとパーティションの配置ルールが無効になる可能性がある問題を修正[＃44031](https://github.com/pingcap/tidb/issues/44031) @ [lcwangchao](https://github.com/lcwangchao)
- テーブル名の変更中に TiCDC が行の変更の一部を失う可能性がある問題を修正[＃43338](https://github.com/pingcap/tidb/issues/43338) @ [tangenta](https://github.com/tangenta)
- BR を使用してテーブルをインポートした後に DDL ジョブ履歴が失われる問題を修正しました [＃43725](https://github.com/pingcap/tidb/issues/43725) @ [tangenta](https://github.com/tangenta)
- - `JSON_OBJECT`場合によってはエラーが報告される可能性がある問題を修正[＃39806](https://github.com/pingcap/tidb/issues/39806) @ [YangKeao](https://github.com/YangKeao)
+ - `JSON_OBJECT`で場合によってはエラーが報告される可能性がある問題を修正[＃39806](https://github.com/pingcap/tidb/issues/39806) @ [YangKeao](https://github.com/YangKeao)
- IPv6環境でクラスターが一部のシステムビューを照会できない問題を修正 [＃43286](https://github.com/pingcap/tidb/issues/43286) @ [Defined2014](https://github.com/Defined2014)
- PDメンバーのアドレスが変更されると、 `AUTO_INCREMENT`列のIDの割り当てが長時間ブロックされる問題を修正[＃42643](https://github.com/pingcap/tidb/issues/42643) @ [tiancaiamao](https://github.com/tiancaiamao)
- 配置ルールのリサイクル中に TiDB が PD に重複したリクエストを送信し、PD ログに多数の`full config reset`エントリが発生する問題を修正しました。 [＃33069](https://github.com/pingcap/tidb/issues/33069) @ [tiancaiamao](https://github.com/tiancaiamao)
diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md
index e8630c6467a1d..bcb08c7bc4c74 100644
--- a/releases/release-6.6.0.md
+++ b/releases/release-6.6.0.md
@@ -201,7 +201,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone
- [GORM](https://github.com/go-gorm/gorm)TiDB 統合テストを追加します。現在、TiDB は GORM によってサポートされるデフォルトのデータベースです。 [#6014](https://github.com/go-gorm/gorm/pull/6014) @[Icemap](https://github.com/Icemap)
- v1.4.6 では、 [GORM MySQL ドライバー](https://github.com/go-gorm/mysql)TiDB [#104](https://github.com/go-gorm/mysql/pull/104)の`AUTO_RANDOM`属性に適応します
- - v1.4.6 では、 [GORM MySQL ドライバー](https://github.com/go-gorm/mysql)TiDB に接続する際に、 `Unique`フィールドの`Unique`属性が`AutoMigrate`中に変更できない問題を修正しました。 [#105](https://github.com/go-gorm/mysql/pull/105)
+ - v1.4.6 では、 [GORM MySQL ドライバー](https://github.com/go-gorm/mysql)は、TiDB に接続する際に、 `Unique`フィールドの`Unique`属性が`AutoMigrate`中に変更できない問題を修正しました。 [#105](https://github.com/go-gorm/mysql/pull/105)
- [GORMドキュメント](https://github.com/go-gorm/gorm.io)TiDB をデフォルトのデータベースとして言及しています [#638](https://github.com/go-gorm/gorm.io/pull/638)
詳細については、 [GORMドキュメント](https://gorm.io/docs/index.html)を参照してください。
diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md
index f37bc4e4bbab8..d0c83e0eeb0bb 100644
--- a/releases/release-7.1.1.md
+++ b/releases/release-7.1.1.md
@@ -114,7 +114,7 @@ TiDB バージョン: 7.1.1
- Backup & Restore (BR)
- - `checksum mismatch`場合によっては誤って報告される問題を修正[＃44472](https://github.com/pingcap/tidb/issues/44472) @ [Leavrth](https://github.com/Leavrth)
+ - `checksum mismatch`が場合によっては誤って報告される問題を修正[＃44472](https://github.com/pingcap/tidb/issues/44472) @ [Leavrth](https://github.com/Leavrth)
- TiDBクラスタにPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 [＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)
- TiCDC
diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md
index 9593c35a58332..7e585987fdbc6 100644
--- a/releases/release-8.1.0.md
+++ b/releases/release-8.1.0.md
@@ -75,7 +75,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。
- TiDB Lightningは競合解決戦略を簡素化し、 `replace`戦略（GA） を使用して競合するデータの処理をサポートします。 [＃51036](https://github.com/pingcap/tidb/issues/51036) @ [lyzx2001](https://github.com/lyzx2001)
- v8.0.0 より前のTiDB Lightningには、論理インポート モードが[1つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#conflict-detection) 、物理インポート モードが[2つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)あり、理解して構成するのは簡単ではありません。
+ v8.0.0 より前のTiDB Lightningには、論理インポート モードが[1つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#conflict-detection) 、物理インポート モードが[2つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)があり、理解して構成するのは簡単ではありません。
TiDB Lightning v8.0.0では、物理インポートモードにおける[競合検出の古いバージョン](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800)戦略が廃止され、 [`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md)パラメータ（実験的）を介して論理インポートモードと物理インポートモードの両方で競合検出戦略を制御できるようになり、このパラメータの設定が簡素化されました。さらに、物理インポートモードでは、 `replace`戦略により、インポート時に主キーまたは一意キーの競合が検出された場合に、最新のデータを保持し、古いデータを上書きすることがサポートされます。v8.1.0では、 `replace`戦略で競合データを処理する機能が一般提供（GA）されます。
diff --git a/resources/markdownlint-rules.md b/resources/markdownlint-rules.md
index f5412ca60c1e8..5f062f1b8acae 100644
--- a/resources/markdownlint-rules.md
+++ b/resources/markdownlint-rules.md
@@ -23,7 +23,7 @@ PRを送信する前に関連するMarkdownルールをよく理解しておら
| 5 | [MD023 - 見出しは行の先頭から始まる必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md023---headings-must-start-at-the-beginning-of-the-line) | 見出しは行頭から始まる必要があります。見出しの`#`文字目より前にスペースは挿入されません。 |
| 6 | [MD026 - 見出しの末尾の句読点](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md026---trailing-punctuation-in-heading) | 見出しの末尾には、疑問符`?` 、バックティック`` ` `` 、二重引用符`"` 、一重引用符`'`といった特定の句読点のみを使用できます。コロン`:` 、コンマ`,` 、ピリオド`.` 、感嘆符`!`といったその他の句読点は、見出しの末尾には使用できません。 |
| 7 | [MD022 - 見出しは空白行で囲む必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md022---headings-should-be-surrounded-by-blank-lines) | 見出しの前後には空白行が必要です。 |
-| 8 | [MD024 - 同じ内容の複数の見出し](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md024---multiple-headings-with-the-same-content) | 文書内で同じ内容の見出しを連続して使用することはできません。例えば、第1レベルの見出しが`# TiDB Architecture`場合、それに続く第2レベルの見出しを`## TiDB Architecture`することはできません。ただし、2つの見出しが連続していない場合は、同じ内容であっても構いません。 |
+| 8 | [MD024 - 同じ内容の複数の見出し](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md024---multiple-headings-with-the-same-content) | 文書内で同じ内容の見出しを連続して使用することはできません。例えば、第1レベルの見出しが`# TiDB Architecture`の場合、それに続く第2レベルの見出しを`## TiDB Architecture`にすることはできません。ただし、2つの見出しが連続していない場合は、同じ内容であっても構いません。 |
| 9 | [MD025 - 同じ文書内に複数のトップレベル見出しがある](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md025---multiple-top-level-headings-in-the-same-document) | 各ドキュメントには、最上位レベルの見出しを1つだけ指定できます。最上位レベルの見出しの前のメタデータ（ `title`と`category`指定）は、このルールに違反しません。 |
| 10 | [MD041 - ファイルの最初の行はトップレベルの見出しである必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md041---first-line-in-file-should-be-a-top-level-heading) | ファイルの最初の行はトップレベルの見出しである必要があります。CIチェックは、ファイルの最初の数行のメタデータを無視し、メタデータの後にトップレベルの見出しがあるかどうかを検査します。 |
| 11 | [MD007 - 順序なしリストのインデント](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md007---unordered-list-indentation) | 通常、リスト項目は`.md`ファイルでは4スペースでインデントされます。唯一の例外は`TOC.md`ファイルで、リスト項目は2スペースでインデントされます。 |
diff --git a/resources/tidb-pdf-generation-tutorial.md b/resources/tidb-pdf-generation-tutorial.md
index eef9969dd5a03..8b118ed9053ec 100644
--- a/resources/tidb-pdf-generation-tutorial.md
+++ b/resources/tidb-pdf-generation-tutorial.md
@@ -1,5 +1,5 @@
---
-title: TiDB Documentation PDF Generation Tutorial
+title: TiDB Documentation PDF Generation Tutorial
summary: 特定のシナリオのニーズに合わせて、TiDB ドキュメントの PDF 出力をローカルでカスタマイズする方法を学習します。
---
@@ -58,11 +58,11 @@ TiDB 英語ドキュメントリポジトリ: [https://github.com/pingcap/docs](
- 方法 2: 次の Git コマンドを使用します。
```shell
- cd $working_dir # Replace `$working_dir` with the directory where you want the repository to be placed. For example, `cd ~/Documents/GitHub`
- git clone git@github.com:$user/docs.git # Replace `$user` with your GitHub ID
-
- cd $working_dir/docs
- git remote add upstream git@github.com:pingcap/docs.git # Add upstream repository
+ cd $working_dir # Replace `$working_dir` with the directory where you want the repository to be placed. For example, `cd ~/Documents/GitHub`
+ git clone git@github.com:$user/docs.git # Replace `$user` with your GitHub ID
+
+ cd $working_dir/docs
+ git remote add upstream git@github.com:pingcap/docs.git # Add upstream repository
git remote -v
```
@@ -87,7 +87,7 @@ TiDB 英語ドキュメントリポジトリ: [https://github.com/pingcap/docs](
docker run -it -v ${doc-path}:/opt/data andelf/doc-build:0.1.9
```
- コマンド中の`${doc-path}` 、PDF生成用のドキュメントのローカルパスです。例えば、パスが`/Users/${username}/Documents/GitHub/docs`場合、コマンドは以下のようになります。
+ コマンド中の`${doc-path}`は、PDF生成用のドキュメントのローカルパスです。例えば、パスが`/Users/${username}/Documents/GitHub/docs`の場合、コマンドは以下のようになります。
```bash
docker run -it -v /Users/${username}/Documents/GitHub/docs:/opt/data andelf/doc-build:0.1.9
diff --git a/role-based-access-control.md b/role-based-access-control.md
index 5f3ce18bbe024..22c2072750b4d 100644
--- a/role-based-access-control.md
+++ b/role-based-access-control.md
@@ -154,7 +154,7 @@ SHOW GRANTS FOR 'read_user1'@'localhost' USING 'app_read';
現在のユーザーの権限を確認するには、 `SHOW GRANTS`または`SHOW GRANTS FOR CURRENT_USER()`使用します。5 と`SHOW GRANTS FOR CURRENT_USER()` `SHOW GRANTS`の点で異なります。
- `SHOW GRANTS` 、現在のユーザーに対して有効なロールの権限を示します。
-- `SHOW GRANTS FOR CURRENT_USER()`場合、有効なロールの権限は表示されません。
+- `SHOW GRANTS FOR CURRENT_USER()`の場合、有効なロールの権限は表示されません。
### デフォルトロールを設定する {#set-the-default-role}
diff --git a/sql-plan-management.md b/sql-plan-management.md
index 1f2d6e2fca969..b3feedb40eef7 100644
--- a/sql-plan-management.md
+++ b/sql-plan-management.md
@@ -37,7 +37,7 @@ SQL ステートメントまたは履歴実行プランに従って、SQL ステ
CREATE [GLOBAL | SESSION] BINDING [FOR BindableStmt] USING BindableStmt;
```
-この文は`UPDATE` SQL実行プランをGLOBALまたはSESSIONレベルでバインドします。現在、TiDBでサポートされているバインド可能なSQL文（BindableStmt）には`DELETE` `SELECT` `INSERT` `REPLACE`あり、それぞれ`SELECT`サブクエリが含まれています。以下に例を示します。
+この文はSQL実行プランをGLOBALまたはSESSIONレベルでバインドします。現在、TiDBでサポートされているバインド可能なSQL文（BindableStmt）には`SELECT` 、 `DELETE` 、 `UPDATE` 、および`SELECT`サブクエリを含む`INSERT` / `REPLACE`があります。以下に例を示します。
```sql
CREATE GLOBAL BINDING USING SELECT /*+ use_index(orders, orders_book_id_idx) */ * FROM orders;
diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md
index 52147e75e1885..3545287b43557 100644
--- a/sql-plan-replayer.md
+++ b/sql-plan-replayer.md
@@ -31,7 +31,7 @@ TiDB は、 `sql-statement`に基づいて、次のオンサイト情報を整
- `EXPLAIN [ANALYZE] sql-statement`の結果
- クエリ最適化の内部手順
-履歴統計が[有効](/system-variables.md#tidb_enable_historical_stats)場合、 `PLAN REPLAYER`文で時刻を指定することで、対応する時刻の履歴統計を取得できます。時刻と日付を直接指定することも、タイムスタンプを指定することもできます。TiDB は指定された時刻より前の履歴統計を検索し、その中から最新のものをエクスポートします。
+履歴統計が[有効](/system-variables.md#tidb_enable_historical_stats)の場合、 `PLAN REPLAYER`文で時刻を指定することで、対応する時刻の履歴統計を取得できます。時刻と日付を直接指定することも、タイムスタンプを指定することもできます。TiDB は指定された時刻より前の履歴統計を検索し、その中から最新のものをエクスポートします。
指定された時刻より前の履歴統計がない場合、TiDBは最新の統計をエクスポートします。これは、時刻が指定されていない場合の動作と一致しています。さらに、TiDBはエクスポートされた`ZIP`ファイル内に、 `errors.txt`ファイル内のエラーメッセージを出力。
diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md
index ee8dce525a4f1..f50d2f983e090 100644
--- a/sql-prepared-plan-cache.md
+++ b/sql-prepared-plan-cache.md
@@ -26,8 +26,8 @@ TiDB の現在のバージョンでは、 `Prepare`ステートメントが次
- クエリには、 `select * from t where a>? and b>@x`などの`?`以外の変数 (システム変数やユーザー定義変数を含む) が含まれています。
- クエリには、キャッシュできない関数`database()` 、 `current_user` 、 `current_role` 、 `user` 、 `connection_id` 、 `last_insert_id` 、 `row_count` 、 `version` 、および`like`が含まれています。
- クエリでは、 `LIMIT`のパラメータとして変数 ( `LIMIT ?`や`LIMIT 10, ?`など) が使用されており、変数の値は 10000 を超えています。
-- クエリには`Order By`後に`?`続きます（例： `Order By ?` ）。このようなクエリは、 `?`で指定された列に基づいてデータをソートします。異なる列をターゲットとするクエリが同じ実行プランを使用すると、結果は正しくありません。そのため、このようなクエリはキャッシュされません。ただし、 `Order By a+?`ように一般的なクエリの場合はキャッシュされます。
-- クエリは`Group By`後に`?`含みます（例： `Group By?` ）。このようなクエリは、 `?`で指定された列に基づいてデータをグループ化します。異なる列をターゲットとするクエリが同じ実行プランを使用すると、結果は正しくありません。そのため、このようなクエリはキャッシュされません。ただし、 `Group By a+?`ように一般的なクエリの場合はキャッシュされます。
+- クエリには`Order By`の後に`?`が続きます（例： `Order By ?` ）。このようなクエリは、 `?`で指定された列に基づいてデータをソートします。異なる列をターゲットとするクエリが同じ実行プランを使用すると、結果は正しくありません。そのため、このようなクエリはキャッシュされません。ただし、 `Order By a+?`のように一般的なクエリの場合はキャッシュされます。
+- クエリは`Group By`の後に`?`を含みます（例： `Group By?` ）。このようなクエリは、 `?`で指定された列に基づいてデータをグループ化します。異なる列をターゲットとするクエリが同じ実行プランを使用すると、結果は正しくありません。そのため、このようなクエリはキャッシュされません。ただし、 `Group By a+?`のように一般的なクエリの場合はキャッシュされます。
- クエリには、ウィンドウ関数`Window Frame`の定義に`?` （ `(partition by year order by sale rows ? preceding)`など）が含まれています。ウィンドウ関数の他の場所に`?`出現する場合、クエリはキャッシュされます。
- このクエリには、 `int`と`string`比較するためのパラメータ`c_int >= ?`や`c_int in (?, ?)`など）が含まれています。ここで、 `?`文字列型（ `set @x='123'`など）を示します。クエリ結果がMySQLと互換性を持つようにするには、各クエリでパラメータを調整する必要があるため、このようなクエリはキャッシュされません。
- このプランは`TiFlash`アクセスしようとします。
diff --git a/sql-statements/sql-statement-create-placement-policy.md b/sql-statements/sql-statement-create-placement-policy.md
index e9d107ee3ee41..9233837695db4 100644
--- a/sql-statements/sql-statement-create-placement-policy.md
+++ b/sql-statements/sql-statement-create-placement-policy.md
@@ -5,7 +5,7 @@ summary: TiDBにおけるCREATE PLACEMENT POLICYの使用方法。
# CREATE PLACEMENT POLICY {#create-placement-policy}
-`CREATE PLACEMENT POLICY`後でテーブル、パーティション、またはデータベーススキーマに割り当てることができる名前付き配置ポリシーを作成するために使用されます。
+`CREATE PLACEMENT POLICY`は、後でテーブル、パーティション、またはデータベーススキーマに割り当てることができる名前付き配置ポリシーを作成するために使用されます。
> **Note:**
>
diff --git a/sql-statements/sql-statement-flush-status.md b/sql-statements/sql-statement-flush-status.md
index abf860f400c89..5dbd9a9328879 100644
--- a/sql-statements/sql-statement-flush-status.md
+++ b/sql-statements/sql-statement-flush-status.md
@@ -5,7 +5,7 @@ summary: TiDB データベースの FLUSH STATUS の使用法の概要。
# FLUSH STATUS {#flush-status}
-このステートメントはMySQLとの互換性のために含まれています。TiDBは`SHOW STATUS`代わりにPrometheusとGrafanaを使用して集中的なメトリクス収集を行うため、このステートメントはTiDBには影響しません。
+このステートメントはMySQLとの互換性のために含まれています。TiDBは`SHOW STATUS`の代わりにPrometheusとGrafanaを使用して集中的なメトリクス収集を行うため、このステートメントはTiDBには影響しません。
## 概要 {#synopsis}
diff --git a/sql-statements/sql-statement-grant-privileges.md b/sql-statements/sql-statement-grant-privileges.md
index c6e408724e2d3..cd05304a28898 100644
--- a/sql-statements/sql-statement-grant-privileges.md
+++ b/sql-statements/sql-statement-grant-privileges.md
@@ -84,7 +84,7 @@ mysql> SHOW GRANTS FOR 'newuser';
- MySQLと同様に、 `USAGE`権限はTiDBサーバーにログインする能力を示します。
- バージョン8.5.6以降、TiDBはMySQL互換の列レベルの権限管理メカニズムをサポートしています。指定したテーブルの特定の列に対して、 `SELECT` 、 `INSERT` 、 `UPDATE` 、および`REFERENCES`権限を付与または取り消すことができます。詳細については、[列レベルの権限管理](/column-privilege-management.md)を参照してください。
- MySQLと同様に、 `NO_AUTO_CREATE_USER` SQLモードが存在しない場合、 `GRANT`ステートメントは、ユーザーが存在しない場合に、パスワードが空の新しいユーザーを自動的に作成します。このSQLモードを削除すると（デフォルトでは有効になっています）、セキュリティ上のリスクが生じます。
-- TiDB では、 `GRANT `ステートメントが正常に実行されると、実行結果は現在の接続に直ちに有効になります。一方[MySQLでは、一部の権限では、実行結果は後続の接続でのみ有効になります](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html)詳細については、 [TiDB #39356](https://github.com/pingcap/tidb/issues/39356)を参照してください。
+- TiDB では、 `GRANT `ステートメントが正常に実行されると、実行結果は現在の接続に直ちに有効になります。一方[MySQLでは、一部の権限では、実行結果は後続の接続でのみ有効になります](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html)。詳細については、 [TiDB #39356](https://github.com/pingcap/tidb/issues/39356)を参照してください。
## 参照 {#see-also}
diff --git a/sql-statements/sql-statement-revoke-privileges.md b/sql-statements/sql-statement-revoke-privileges.md
index 633a6c4371483..a6e5b39da0c05 100644
--- a/sql-statements/sql-statement-revoke-privileges.md
+++ b/sql-statements/sql-statement-revoke-privileges.md
@@ -96,7 +96,7 @@ ERROR 1141 (42000): There is no such grant defined for user 'newuser' on host '%
## MySQLとの互換性 {#mysql-compatibility}
-- TiDB では、 `REVOKE `ステートメントが正常に実行されると、実行結果は現在の接続に直ちに有効になります。一方[MySQLでは、一部の権限では、実行結果は後続の接続でのみ有効になります](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html)詳細については、 [TiDB #39356](https://github.com/pingcap/tidb/issues/39356)を参照してください。
+- TiDB では、 `REVOKE `ステートメントが正常に実行されると、実行結果は現在の接続に直ちに有効になります。一方[MySQLでは、一部の権限では、実行結果は後続の接続でのみ有効になります](https://dev.mysql.com/doc/refman/8.0/en/privilege-changes.html)。詳細については、 [TiDB #39356](https://github.com/pingcap/tidb/issues/39356)を参照してください。
## 参照 {#see-also}
diff --git a/sql-statements/sql-statement-show-bindings.md b/sql-statements/sql-statement-show-bindings.md
index 1dd3aa00a4205..e511248c88c87 100644
--- a/sql-statements/sql-statement-show-bindings.md
+++ b/sql-statements/sql-statement-show-bindings.md
@@ -5,7 +5,7 @@ summary: TiDB データベースでの SHOW BINDINGS バインディングの使
# SHOW [GLOBAL|SESSION] BINDINGS {#show-global-session-bindings}
-`SHOW BINDINGS`ステートメントは、作成されたSQLバインディングに関する情報を表示するために使用されます。 `BINDING` `GLOBAL`または`SESSION`いずれかの基準で表されます。デフォルトは`SESSION`です。
+`SHOW BINDINGS`ステートメントは、作成されたSQLバインディングに関する情報を表示するために使用されます。 `BINDING`は`GLOBAL`または`SESSION`のいずれかの基準で表されます。デフォルトは`SESSION`です。
## 概要 {#synopsis}
diff --git a/sql-statements/sql-statement-show-stats-buckets.md b/sql-statements/sql-statement-show-stats-buckets.md
index 1fbd919705a03..cbd144b6437ee 100644
--- a/sql-statements/sql-statement-show-stats-buckets.md
+++ b/sql-statements/sql-statement-show-stats-buckets.md
@@ -14,7 +14,7 @@ summary: TiDB データベースの SHOW STATS_BUCKETS の使用法の概要。
| `Db_name` | データベース名 |
| `Table_name` | テーブル名 |
| `Partition_name` | パーティション名 |
-| `Column_name` | 列名（ `is_index`が`0`場合）またはインデックス名（ `is_index`が`1`場合） |
+| `Column_name` | 列名（ `is_index`が`0`の場合）またはインデックス名（ `is_index`が`1`の場合） |
| `Is_index` | インデックス列であるかどうか |
| `Bucket_id` | バケットのID |
| `Count` | バケットとその前のバケットに含まれるすべての値の数 |
diff --git a/sql-statements/sql-statement-show-stats-histograms.md b/sql-statements/sql-statement-show-stats-histograms.md
index 8da3d13e5e15c..6d8bd265a3d13 100644
--- a/sql-statements/sql-statement-show-stats-histograms.md
+++ b/sql-statements/sql-statement-show-stats-histograms.md
@@ -14,7 +14,7 @@ summary: TiDB データベースの SHOW STATS_HISTOGRAMS の使用法の概要
| `Db_name` | データベース名 |
| `Table_name` | テーブル名 |
| `Partition_name` | パーティション名 |
-| `Column_name` | 列名（ `is_index`が`0`場合）またはインデックス名（ `is_index`が`1`場合） |
+| `Column_name` | 列名（ `is_index`が`0`の場合）またはインデックス名（ `is_index`が`1`の場合） |
| `Is_index` | インデックス列であるかどうか |
| `Update_time` | 更新時間 |
| `Distinct_count` | 個別カウント |
diff --git a/sql-statements/sql-statement-show-stats-topn.md b/sql-statements/sql-statement-show-stats-topn.md
index 1a75b72cfa02a..4c97d85681017 100644
--- a/sql-statements/sql-statement-show-stats-topn.md
+++ b/sql-statements/sql-statement-show-stats-topn.md
@@ -14,7 +14,7 @@ summary: TiDB データベースの SHOW STATS_TOPN の使用法の概要。
| `Db_name` | データベース名 |
| `Table_name` | テーブル名 |
| `Partition_name` | パーティション名 |
-| `Column_name` | 列名（ `is_index`が`0`場合）またはインデックス名（ `is_index`が`1`場合） |
+| `Column_name` | 列名（ `is_index`が`0`の場合）またはインデックス名（ `is_index`が`1`の場合） |
| `Is_index` | インデックス列であるかどうか |
| `Value` | この列の値 |
| `Count` | 値が何回出現するか |
diff --git a/sql-statements/sql-statement-with.md b/sql-statements/sql-statement-with.md
index 2bdf346f7895e..f0bdfae07b081 100644
--- a/sql-statements/sql-statement-with.md
+++ b/sql-statements/sql-statement-with.md
@@ -75,7 +75,7 @@ WITH RECURSIVE cte(a) AS (SELECT 1 UNION SELECT a+1 FROM cte WHERE a < 5) SELECT
- 厳密モードでは、再帰的に計算されたデータ長がシード部分のデータ長を超えると、TiDBは警告を返し、MySQLはエラーを返します。非厳密モードでは、TiDBの動作はMySQLの動作と一致します。
- 再帰CTEのデータ型はシード部によって決定されます。シード部のデータ型は、場合によってはMySQLと完全に一致しないことがあります（関数など）。
-- 複数の`UNION` / `UNION ALL`演算子の場合、MySQL では`UNION`後に`UNION ALL`続くことは許可されませんが、TiDB では許可されます。
+- 複数の`UNION` / `UNION ALL`演算子の場合、MySQL では`UNION`の後に`UNION ALL`が続くことは許可されませんが、TiDB では許可されます。
- CTE の定義に問題がある場合、TiDB はエラーを報告しますが、MySQL は CTE が参照されていない場合はエラーを報告しません。
## 参照 {#see-also}
diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md
index 9e5140d35fe3f..50f6017d7fb1a 100644
--- a/sql-tuning-best-practice.md
+++ b/sql-tuning-best-practice.md
@@ -299,7 +299,7 @@ TiDBオプティマイザは、統計情報を用いてSQL文の各ステップ
次の図は、コストベース最適化において考慮される様々なデータアクセスパスと行セット操作を示しています。データ取得パスについては、オプティマイザーはインデックススキャンとフルテーブルスキャンのどちらが最も効率的な方法であるかを判断し、行ベースのTiKVストレージと列指向のTiFlashストレージのどちらからデータを取得するかを決定します。
-オプティマイザは、集計、結合、ソートなど、行セットを操作する操作も評価します。例えば、集計演算子では`HashAgg`または`StreamAgg`いずれかが使用される可能性がありますが、結合方法では`HashJoin` 、 `MergeJoin` 、または`IndexJoin`いずれかが選択されます。
+オプティマイザは、集計、結合、ソートなど、行セットを操作する操作も評価します。例えば、集計演算子では`HashAgg`または`StreamAgg`のいずれかが使用される可能性がありますが、結合方法では`HashJoin` 、 `MergeJoin` 、または`IndexJoin`のいずれかが選択されます。
さらに、物理最適化フェーズでは、式と演算子を物理ストレージエンジンにプッシュダウンします。物理プランは、基盤となるストレージエンジンに基づいて、以下のように異なるコンポーネントに分配されます。
@@ -688,7 +688,7 @@ LIMIT
実行プランには170ミリ秒の期間が表示されています。TiDBは`test_index`使用して、フィルター`snapshot_id = 459840`で`IndexRangeScan_20`実行します。次に、テーブルからすべての列を取得し、 `IndexLookUp_23`後に5,715行をTiDBに返します。TiDBはこれらの行をソートし、1,000行を返します。
-列`id`は主キーであるため、暗黙的にインデックス`test_idx`に含まれます。ただし、 `IndexRangeScan_20`順序を保証しません。これは、列`test_idx`はインデックスプレフィックス列`snapshot_id`後に 2 つの追加列（ `user_id`と`status` ）が含まれているためです。その結果、列`id`の順序は保持されません。
+列`id`は主キーであるため、暗黙的にインデックス`test_idx`に含まれます。ただし、 `IndexRangeScan_20`は順序を保証しません。これは、列`test_idx`はインデックスプレフィックス列`snapshot_id`の後に 2 つの追加列（ `user_id`と`status` ）が含まれているためです。その結果、列`id`の順序は保持されません。
当初の計画は次のとおりです。
diff --git a/statistics.md b/statistics.md
index 96d89643f2035..55c6d26e7aaa1 100644
--- a/statistics.md
+++ b/statistics.md
@@ -749,7 +749,7 @@ TiDB v6.0以降、TiDBは`KILL`ステートメントを使用して、バック
#### `tidb_build_stats_concurrency` {#tidb-build-stats-concurrency}
-`ANALYZE`ステートメントを実行すると、タスクは複数の小さなタスクに分割されます。各タスクは、1 つの列またはインデックスの統計情報のみを処理します。tidb_build_stats_concurrency 変数を使用して、同時実行される小さなタスクの数を制御できます。 [`tidb_build_stats_concurrency`](/system-variables.md#tidb_build_stats_concurrency)値は`2`です。v7.4.0 以前のバージョンでは、デフォルト値は`4`です。
+`ANALYZE`ステートメントを実行すると、タスクは複数の小さなタスクに分割されます。各タスクは、1 つの列またはインデックスの統計情報のみを処理します。tidb_build_stats_concurrency 変数を使用して、同時実行される小さなタスクの数を制御できます。 [`tidb_build_stats_concurrency`](/system-variables.md#tidb_build_stats_concurrency)のデフォルト値は`2`です。v7.4.0 以前のバージョンでは、デフォルト値は`4`です。
#### `tidb_build_sampling_stats_concurrency` {#tidb-build-sampling-stats-concurrency}
diff --git a/system-variables.md b/system-variables.md
index 944803d1e43e9..54e9587623b82 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -1612,7 +1612,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー
> **Note:**
>
-> - TiDB v6.5.0以降では、新しく作成されたクラスタはデフォルトでコストモデルバージョン2を使用します。TiDBバージョンをv6.5.0より前のバージョンからv6.5.0以降にアップグレードした場合、 `tidb_cost_model_version`値は変更されません。
+> - TiDB v6.5.0以降では、新しく作成されたクラスタはデフォルトでコストモデルバージョン2を使用します。TiDBバージョンをv6.5.0より前のバージョンからv6.5.0以降にアップグレードした場合、 `tidb_cost_model_version`の値は変更されません。
> - コストモデルのバージョンを変更すると、実行プランに変更が生じる可能性があります。
- 範囲: セッション | グローバル
diff --git a/temporary-tables.md b/temporary-tables.md
index dca1427c2e3ad..8781ffebf344a 100644
--- a/temporary-tables.md
+++ b/temporary-tables.md
@@ -129,7 +129,7 @@ TiDB ローカル一時テーブルの次の機能と制限は、MySQL 一時テ
- ローカル一時テーブルの作成には権限`CREATE TEMPORARY TABLES`必要です。それ以降のテーブルに対する操作には権限は必要ありません。
- ローカル一時テーブルは外部キーとパーティション化されたテーブルをサポートしません。
- ローカル一時テーブルに基づくビューの作成はサポートされていません。
-- `SHOW [FULL] TABLES`場合、ローカル一時テーブルは表示されません。
+- `SHOW [FULL] TABLES`の場合、ローカル一時テーブルは表示されません。
TiDB のローカル一時テーブルは、次の点で MySQL の一時テーブルと互換性がありません。
diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md
index 26179c694c7f4..dabfc8b5926a4 100644
--- a/ticdc/ticdc-canal-json.md
+++ b/ticdc/ticdc-canal-json.md
@@ -77,9 +77,9 @@ TiCDC は、DDL イベントを次の Canal-JSON 形式にエンコードしま
| タイプ | string | Canal-JSONで定義されたイベントタイプ |
| es | number | メッセージを生成したイベントが発生したときの13ビット（ミリ秒）のタイムスタンプ |
| ts | number | TiCDC がメッセージを生成した時の 13 ビット (ミリ秒) のタイムスタンプ |
-| SQL | string | isDdlが`true`場合、対応するDDL文を記録します。 |
-| sqlType | object | isDdlが`false`場合、各列のデータ型がJavaでどのように表現されるかを記録します。 |
-| mysqlType | object | isDdlが`false`場合、各列のデータ型がMySQLでどのように表現されるかを記録します。 |
+| SQL | string | isDdlが`true`の場合、対応するDDL文を記録します。 |
+| sqlType | object | isDdlが`false`の場合、各列のデータ型がJavaでどのように表現されるかを記録します。 |
+| mysqlType | object | isDdlが`false`の場合、各列のデータ型がMySQLでどのように表現されるかを記録します。 |
| データ | object | isDdlが`false`の場合、各列の名前とそのデータ値を記録します。 |
| 古い | object | メッセージが更新イベントによって生成された場合のみ、更新前の各列の名前とデータ値を記録します。 |
| _tidb | object | TiDB拡張フィールド。1 を`enable-tidb-extension` `true`設定した場合にのみ存在します。5 `commitTs`値は、行の変更を引き起こしたトランザクションのTSOです。 |
@@ -167,8 +167,8 @@ TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERM
上記の例からわかるように、Canal-JSON は統一されたデータ形式を持ち、イベントの種類ごとに異なるフィールドの入力ルールを備えています。コンシューマーは、統一された方法でこの JSON 形式のデータを解析し、フィールド値をチェックすることでイベントの種類を判別できます。
-- `isDdl`が`true`場合、メッセージには DDL イベントが含まれます。
-- `isDdl`が`false`場合、 `type`フィールドをさらに確認する必要があります。7 が`type` `TIDB_WATERMARK`場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。
+- `isDdl`が`true`の場合、メッセージには DDL イベントが含まれます。
+- `isDdl`が`false`の場合、 `type`フィールドをさらに確認する必要があります。`type`が`TIDB_WATERMARK`の場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。
## フィールドの説明 {#field-descriptions}
@@ -300,7 +300,7 @@ TiCDCにおけるCanal-JSONデータ形式の実装方法（ `Update`イベン
| アイテム | TiCDC Canal-JSON | Canal |
| :--------------- | :----------------------------------------------------------------------------------------------------------- | :------------------------------- |
-| `Update`種類のイベント | デフォルトでは、 `old`フィールドにはすべての列データが含まれます。3が`only_output_updated_columns` `true`場合、 `old`フィールドには変更された列データのみが含まれます。 | `old`フィールドは変更された列データのみを含みます |
+| `Update`種類のイベント | デフォルトでは、 `old`フィールドにはすべての列データが含まれます。`only_output_updated_columns`が`true`の場合、 `old`フィールドには変更された列データのみが含まれます。 | `old`フィールドは変更された列データのみを含みます |
| `mysqlType`フィールド | パラメータを持つ型の場合、型パラメータの情報は含まれません。 | パラメータを持つ型の場合、型パラメータの完全な情報が含まれます。 |
### 公式Canalとの互換性 {#compatibility-with-the-official-canal}
diff --git a/ticdc/ticdc-client-authentication.md b/ticdc/ticdc-client-authentication.md
index 348fcc784d9d5..67e7669ac2b07 100644
--- a/ticdc/ticdc-client-authentication.md
+++ b/ticdc/ticdc-client-authentication.md
@@ -14,7 +14,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB
> **Note:**
>
-> ネットワークアクセスのセキュリティを確保するため、TiCDC クライアント認証は[TLSが有効になっています](/enable-tls-between-clients-and-servers.md)場合にのみ使用することを強くお勧めします。TLS が有効になっていない場合、ユーザー名とパスワードはネットワーク上でプレーンテキストとして送信され、深刻な資格情報漏洩につながる可能性があります。
+> ネットワークアクセスのセキュリティを確保するため、TiCDC クライアント認証は[TLSが有効になっている](/enable-tls-between-clients-and-servers.md)場合にのみ使用することを強くお勧めします。TLS が有効になっていない場合、ユーザー名とパスワードはネットワーク上でプレーンテキストとして送信され、深刻な資格情報漏洩につながる可能性があります。
## クライアント認証にmTLSを使用する {#use-mtls-for-client-authentication}
diff --git a/ticdc/ticdc-debezium.md b/ticdc/ticdc-debezium.md
index 6dea71fa76b6c..0967ef903da9c 100644
--- a/ticdc/ticdc-debezium.md
+++ b/ticdc/ticdc-debezium.md
@@ -154,7 +154,7 @@ TiCDC は、キーと値の両方を Debezium 形式でエンコードして、D
| :------------------- | :----- | :------------------------------------------------------------------------------------------------------------------------------- |
| payload.op | String | 変更イベントのタイプ。1 `"c"` `INSERT`イベント、 `"u"` `UPDATE`イベント、 `"d"` `DELETE`イベントを示します。 |
| payload.ts_ms | number | TiCDC がこのメッセージを生成したときのタイムスタンプ (ミリ秒単位)。 |
-| payload.before | JSON | ステートメントの変更イベント前のデータ値。イベントが`"c"`場合、フィールド`before`の値は`null`なります。 |
+| payload.before | JSON | ステートメントの変更イベント前のデータ値。イベントが`"c"`の場合、フィールド`before`の値は`null`になります。 |
| payload.after | JSON | The data value after the change event of a statement. For `"d"` events, the value of the `after` field is `null`. |
| payload.source.commit_ts | number | TiCDC がこのメッセージを生成するときの`CommitTs`識別子。 |
| payload.source.db | string | イベントが発生したデータベースの名前。 |
diff --git a/ticdc/ticdc-integrity-check.md b/ticdc/ticdc-integrity-check.md
index 6b35442021e28..f6207798c7a2f 100644
--- a/ticdc/ticdc-integrity-check.md
+++ b/ticdc/ticdc-integrity-check.md
@@ -98,7 +98,7 @@ For clusters created in v8.4.0 or later, or clusters upgraded to v8.4.0 or later
- BIT, ENUM, and SET types are converted to UINT64.
- BIT 型はバイナリ形式の UINT64 に変換されます。
- - ENUM型とSET型は、UINT64の対応するINT値に変換されます。例えば、 `SET('a','b','c')`型の列のデータ値が`'a,c'`場合、その値は`0b101` （10進数では`5`としてエンコードされます。
+ - ENUM型とSET型は、UINT64の対応するINT値に変換されます。例えば、 `SET('a','b','c')`型の列のデータ値が`'a,c'`の場合、その値は`0b101` （10進数では`5`）としてエンコードされます。
- TIMESTAMP、DATE、DURATION、DATETIME、JSON、および DECIMAL 型は、最初に STRING に変換され、次にバイトに変換されます。
diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md
index 8448ed66da974..a030829d1f045 100644
--- a/ticdc/ticdc-open-api-v2.md
+++ b/ticdc/ticdc-open-api-v2.md
@@ -808,7 +808,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1/synced
- `puller_resolved_ts` : PD 時間での、プラー モジュールのresolved-ts値。
- `last_synced_ts` : TiCDC によって処理された最新のデータの commit-ts 値 (PD 時間)。
- `now_ts` : 現在の PD 時間。
-- `info` : 特に`synced`が`false`場合、同期ステータスの判別を支援する補足情報。
+- `info` : 特に`synced`が`false`の場合、同期ステータスの判別を支援する補足情報。
**例2: 同期が完了していない**
diff --git a/ticdc/ticdc-open-protocol.md b/ticdc/ticdc-open-protocol.md
index 5ccbfcfd7a618..f837c816b8115 100644
--- a/ticdc/ticdc-open-protocol.md
+++ b/ticdc/ticdc-open-protocol.md
@@ -374,5 +374,5 @@ COMMIT;
> **Note:**
>
-> - `BinaryFlag` 、列の型が BLOB/ TEXT （TINYBLOB/TINYTEXT、BINARY/CHAR を含む）の場合にのみ意味を持ちます。上流の列が BLOB 型の場合、 `BinaryFlag`値は`1`に設定されます。上流の列がTEXT型の場合、 `BinaryFlag`値は`0`に設定されます。
+> - `BinaryFlag`は、列の型が BLOB/ TEXT （TINYBLOB/TINYTEXT、BINARY/CHAR を含む）の場合にのみ意味を持ちます。上流の列が BLOB 型の場合、 `BinaryFlag`の値は`1`に設定されます。上流の列がTEXT型の場合、 `BinaryFlag`の値は`0`に設定されます。
> - TiCDCは、上流からテーブルを複製するために、ハンドルインデックスとして[有効なインデックス](/ticdc/ticdc-overview.md#best-practices)選択します。ハンドルインデックス列の`HandleKeyFlag`の値は`1`に設定されます。
diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md
index dda9e120d3ca8..045ef16dec0a9 100644
--- a/ticdc/ticdc-sink-to-kafka.md
+++ b/ticdc/ticdc-sink-to-kafka.md
@@ -82,7 +82,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na
| `required-acks` | `Produce`リクエストで使用されるパラメータ。ブローカーが応答するまでに受信する必要があるレプリカ確認応答の数を通知します。値のオプションは`0` ( `NoResponse` : 応答なし、 `TCP ACK`のみ提供)、 `1` ( `WaitForLocal` : ローカルコミットが正常に送信された後にのみ応答)、および`-1` ( `WaitForAll` : すべての複製レプリカが正常にコミットされた後に応答) です。複製レプリカの最小数は、ブローカーの[`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)設定項目を使用して設定できます。(オプション、デフォルト値は`-1` )。 |
| `compression` | メッセージを送信する際に使用する圧縮アルゴリズム（値の選択肢は`none` 、 `lz4` 、 `gzip` 、 `snappy` 、 `zstd` 。デフォルトは`none` ）。Snappy圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)である必要があります。その他のSnappy圧縮形式はサポートされていません。 |
| `auto-create-topic` | 渡された`topic-name` Kafka クラスターに存在しない場合に、TiCDC がトピックを自動的に作成するかどうかを決定します (オプション、デフォルトは`true` )。 |
-| `enable-tidb-extension` | オプション。デフォルトは`false` 。出力プロトコルが`canal-json`場合、値が`true`であれば、TiCDC は[ウォーターマークイベント](/ticdc/ticdc-canal-json.md#watermark-event)送信し、Kafka メッセージに[TiDB拡張フィールド](/ticdc/ticdc-canal-json.md#tidb-extension-field)を追加します。v6.1.0 以降では、このパラメータは`avro`プロトコルにも適用されます。値が`true`であれば、TiCDC は Kafka メッセージに[3つのTiDB拡張フィールド](/ticdc/ticdc-avro-protocol.md#tidb-extension-fields)追加します。 |
+| `enable-tidb-extension` | オプション。デフォルトは`false` 。出力プロトコルが`canal-json`の場合、値が`true`であれば、TiCDC は[ウォーターマークイベント](/ticdc/ticdc-canal-json.md#watermark-event)を送信し、Kafka メッセージに[TiDB拡張フィールド](/ticdc/ticdc-canal-json.md#tidb-extension-field)を追加します。v6.1.0 以降では、このパラメータは`avro`プロトコルにも適用されます。値が`true`であれば、TiCDC は Kafka メッセージに[3つのTiDB拡張フィールド](/ticdc/ticdc-avro-protocol.md#tidb-extension-fields)追加します。 |
| `max-batch-size` | v4.0.9 の新機能。メッセージプロトコルが 1 つの Kafka メッセージに複数のデータ変更を出力することをサポートしている場合、このパラメータは 1 つの Kafka メッセージに含まれるデータ変更の最大数を指定します。現在、このパラメータは Kafka の`protocol`が`open-protocol` （オプション、デフォルトは`16` ）の場合にのみ有効です。 |
| `enable-tls` | ダウンストリーム Kafka インスタンスに接続するために TLS を使用するかどうか (オプション、デフォルトは`false` )。 |
| `ca` | ダウンストリーム Kafka インスタンスに接続するために必要な CA 証明書ファイルのパス (オプション)。 |
@@ -115,7 +115,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na
> **Note:**
>
-> `protocol`が`open-protocol`場合、TiCDC は複数のイベントを 1 つの Kafka メッセージにエンコードし、 `max-message-bytes`で指定された長さを超えるメッセージの生成を回避します。1 行の変更イベントのエンコード結果が`max-message-bytes`を超える場合、changefeed はエラーを報告し、ログを出力。
+> `protocol`が`open-protocol`の場合、TiCDC は複数のイベントを 1 つの Kafka メッセージにエンコードし、 `max-message-bytes`で指定された長さを超えるメッセージの生成を回避します。1 行の変更イベントのエンコード結果が`max-message-bytes`を超える場合、changefeed はエラーを報告し、ログを出力。
### TiCDCはKafkaの認証と認可を使用します {#ticdc-uses-the-authentication-and-authorization-of-kafka}
diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md
index fc04b6a393198..2047f443ad2e7 100644
--- a/ticdc/ticdc-sink-to-pulsar.md
+++ b/ticdc/ticdc-sink-to-pulsar.md
@@ -63,7 +63,7 @@ URI で設定可能なパラメータは次のとおりです。
| パラメータ | 説明 |
| :---------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `pulsar` | 下流Pulsarのスキーム。値は`pulsar` 、 `pulsar+ssl` 、 `pulsar+http` 、 `pulsar+https`いずれかで、v8.2.0以降では`pulsar+http`と`pulsar+https`サポートされています。 |
+| `pulsar` | 下流Pulsarのスキーム。値は`pulsar` 、 `pulsar+ssl` 、 `pulsar+http` 、 `pulsar+https`のいずれかで、v8.2.0以降では`pulsar+http`と`pulsar+https`がサポートされています。 |
| `127.0.0.1` | ダウンストリーム Pulsar がサービスを提供する IP アドレス。 |
| `6650` | 下流 Pulsar の接続ポート。 |
| `persistent://abc/def/yktest` | 前の構成例 1 に示されているように、このパラメータは Pulsar のテナント、名前空間、トピックを指定するために使用されます。 |
@@ -296,7 +296,7 @@ dispatchers = [
- `test4`下にあるすべてのテーブルのデータ変更イベントは、 `hello_test4_world`という名前のトピックに送信されます。
- `matcher = ['*.*'], topic = "{schema}_{table}"`
- - TiCDCがリッスンするすべてのテーブルは、ルール`databaseName_tableName`に従って別々のトピックに送信されます。例えば、テーブル`test.account`場合、TiCDCはデータ変更ログをトピック`test_account`に送信します。
+ - TiCDCがリッスンするすべてのテーブルは、ルール`databaseName_tableName`に従って別々のトピックに送信されます。例えば、テーブル`test.account`の場合、TiCDCはデータ変更ログをトピック`test_account`に送信します。
### DDLイベントをディスパッチする {#dispatch-ddl-events}
@@ -310,9 +310,9 @@ dispatchers = [
たとえば、 `matcher = ['test.*'], topic = {schema}_{table}`ような`dispatchers`構成の場合、DDL イベントは次のように送信されます。
-- DDLイベントが単一のテーブルのみに関係する場合、DDLイベントはそのまま適切なトピックにディスパッチされます。例えば、DDLイベント`DROP TABLE test.table1`場合、イベントは`test_table1`名前のトピックにディスパッチされます。
+- DDLイベントが単一のテーブルのみに関係する場合、DDLイベントはそのまま適切なトピックにディスパッチされます。例えば、DDLイベント`DROP TABLE test.table1`の場合、イベントは`test_table1`という名前のトピックにディスパッチされます。
-- DDLイベントが複数のテーブルに関係する場合（ `RENAME TABLE` 、 `DROP TABLE` 、 `DROP VIEW`いずれも複数のテーブルに関係する可能性があります）、単一のDDLイベントは複数のイベントに分割され、適切なトピックにディスパッチされます。例えば、DDLイベント`RENAME TABLE test.table1 TO test.table10, test.table2 TO test.table20`場合、処理は次のようになります。
+- DDLイベントが複数のテーブルに関係する場合（ `RENAME TABLE` 、 `DROP TABLE` 、 `DROP VIEW`のいずれも複数のテーブルに関係する可能性があります）、単一のDDLイベントは複数のイベントに分割され、適切なトピックにディスパッチされます。例えば、DDLイベント`RENAME TABLE test.table1 TO test.table10, test.table2 TO test.table20`の場合、処理は次のようになります。
- `RENAME TABLE test.table1 TO test.table10`の DDL イベントを`test_table1`という名前のトピックにディスパッチします。
- `RENAME TABLE test.table2 TO test.table20`の DDL イベントを`test_table2`という名前のトピックにディスパッチします。
diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md
index 2d06a3125f1aa..3ef349f8ba15e 100644
--- a/tidb-cloud/data-service-api-key.md
+++ b/tidb-cloud/data-service-api-key.md
@@ -26,7 +26,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access
- TiDB Cloud Data Serviceでは、デフォルトではAPIキーごとに1分あたり最大100件のリクエスト（rpm）が許可されています。
- API キーのレート制限は、キー[作成する](#create-an-api-key)または[編集](#edit-an-api-key)ときに編集できます。サポートされている値の範囲は、 `1`から`1000`です。 1 分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1000 rpm を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ができます。
+ API キーのレート制限は、キーを[作成する](#create-an-api-key)または[編集](#edit-an-api-key)するときに編集できます。サポートされている値の範囲は、 `1`から`1000`です。 1 分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1000 rpm を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ことができます。
各APIリクエストは、制限に関する以下のヘッダーを返します。
@@ -55,7 +55,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access
## APIキーの有効期限 {#api-key-expiration}
-デフォルトでは、API キーは期限切れになりません。ただし、セキュリティを考慮して、キー[作成する](#create-an-api-key)または[編集](#edit-an-api-key)ときに API キーの有効期限を指定できます。
+デフォルトでは、API キーは期限切れになりません。ただし、セキュリティを考慮して、キーを[作成する](#create-an-api-key)または[編集](#edit-an-api-key)するときに API キーの有効期限を指定できます。
- APIキーは有効期限までのみ有効です。有効期限が切れると、そのキーを使用したすべてのリクエストは`401`エラーで失敗し、応答は次のようになります。
diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md
index 3fbf398dd538a..09a5bab760522 100644
--- a/tidb-cloud/releases/tidb-cloud-release-notes.md
+++ b/tidb-cloud/releases/tidb-cloud-release-notes.md
@@ -358,7 +358,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes']
**APIの変更**
-- TiDB Cloud StarterおよびEssentialインスタンスの`project_id`値は、 TiDB Cloudコンソールでプロジェクト間でインスタンスを移動できるため、**変更される可能性があります**。 `project_id`値をハードコーディングしないでください。
+- TiDB Cloud StarterおよびEssentialインスタンスの`project_id`の値は、 TiDB Cloudコンソールでプロジェクト間でインスタンスを移動できるため、**変更される可能性があります**。 `project_id`の値をハードコーディングしないでください。
- `type`フィールド[アクセス可能なプロジェクトをすべて一覧表示します](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project/operation/ListProjects)に追加します。
diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md
index a747ffef6068d..b5275072dca35 100644
--- a/tidb-cloud/serverless-limitations.md
+++ b/tidb-cloud/serverless-limitations.md
@@ -27,7 +27,7 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを
> **Note:**
>
-> [AWS Global Acceleratorの制限](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-how-it-works.html#about-idle-timeout)ため、AWS のパブリックエンドポイント接続のアイドルタイムアウトは 340 秒です。同じ理由から、TCP キープアライブパケットを使用して接続を維持することはできません。
+> [AWS Global Acceleratorの制限](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-how-it-works.html#about-idle-timeout)のため、AWS のパブリックエンドポイント接続のアイドルタイムアウトは 340 秒です。同じ理由から、TCP キープアライブパケットを使用して接続を維持することはできません。
### 暗号化 {#encryption}
diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md
index d0741c008af2a..5a3326dbeac2e 100644
--- a/tidb-cloud/serverless-private-link-connection.md
+++ b/tidb-cloud/serverless-private-link-connection.md
@@ -212,7 +212,7 @@ TiDB Cloudコンソールを使用してドメインをプライベート リン
5. **[ドメインの接続]**ダイアログで、ドメインの種類を選択します。
- - **TiDB Cloud管理**：ドメインはTiDB Cloudによって自動的に生成されます。生成されたドメインの名前には、そのドメインの一意の名前が付与されます。例えば、生成されたドメインが`*.use1-az1.dvs6nl5jgveztmla3pxkxgh76i.aws.plc.tidbcloud.com`場合、一意の名前は`dvs6nl5jgveztmla3pxkxgh76i`になります。 **「ドメインをアタッチ」**をクリックして確定します。
+ - **TiDB Cloud管理**：ドメインはTiDB Cloudによって自動的に生成されます。生成されたドメインの名前には、そのドメインの一意の名前が付与されます。例えば、生成されたドメインが`*.use1-az1.dvs6nl5jgveztmla3pxkxgh76i.aws.plc.tidbcloud.com`の場合、一意の名前は`dvs6nl5jgveztmla3pxkxgh76i`になります。 **「ドメインをアタッチ」**をクリックして確定します。
- **Confluent Cloud** : Confluent Cloud Dedicatedクラスタからドメインを生成するために提供された一意の名前を入力し、 **「ドメインをアタッチ」を**クリックして確定します。一意の名前の取得方法の詳細については、 [プライベートリンク接続を介してConfluent Cloudに接続する](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md#step-1-set-up-a-confluent-cloud-network)を参照してください。