From 4de0c31e4031a2712ed2b2f90a2c44156afb724d Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 14:54:39 +0900 Subject: [PATCH 01/14] i18n(ja): fix defects found in dedicated review of 6 MEGA files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reviewed 7 large top-level files that had never gotten a dedicated defect-review round (system-variables.md, tikv-configuration-file.md, pd-control.md, optimizer-hints.md, sql-tuning-best-practice.md, sql-plan-management.md, latency-breakdown.md), comparing each 1:1 against its English source. sql-tuning-best-practice.md had zero genuine defects; the other 6 needed fixes: - optimizer-hints.md: 3 hint-name/placeholder headings were translated as Japanese prose instead of being kept as the literal identifier (STRAIGHT_JOIN(), RESOURCE_GROUP(resource_group_name), SET_VAR(VAR_NAME=VAR_VALUE)), inconsistent with every sibling heading in the file; plus one dropped に particle. - tikv-configuration-file.md: 6 sites using the HTML entity `>` where EN uses a literal `>` (or `\>` in one MDX-escaped case), missed by the earlier corpus-wide entity sweep (PR #23570) since this file was never included in it. - pd-control.md: 8 dropped は particles (code-span subject followed by a bare comma instead of は before the verb, breaking 8 config- option descriptions), plus one mistranslation from a garden-path reading of an awkward EN sentence ("factors in" parsed as a noun instead of a verb). - sql-plan-management.md: a dropped は particle, an ungrammatical ずつ usage, a missing colon before a trailing code span, a missing "/" between PREPARE and EXECUTE (2 occurrences), and 3 more `>` entity-vs-literal mismatches on one line. - latency-breakdown.md: the term "PointGet" was inconsistently rendered (獲得中/取得中/バッチPointGet) in 3 places instead of matching this file's own heading convention of keeping PointGet / Batch PointGet in English; plus one verb-to-noun fix for parallel list structure (提案する -> 提案, matching コミット/適用). - system-variables.md: two duplicated-word typos (照合照合順序 -> 照合順序); a genuine Scope/Range label collision affecting 126 variable entries where both the Scope field and a numeric Range field were labeled "範囲:" in the same entry, making them indistinguishable (unified the Scope label to the already-used alternate "対象範囲：" only where it collided with a Range field, not the ~169 non-colliding entries using either label, which is pure notation variance out of scope here); 18 zero-width-space (U+200B) MT artifacts removed; 2 dropped が/を particles in the tidb_restricted_read_only cross-effect bullet list; one value description rephrased from an imperative command ("...しないでください") to a declarative description ("...しません"), matching EN's descriptive (not imperative) phrasing and the style of sibling value descriptions. Co-Authored-By: Claude Sonnet 5 --- latency-breakdown.md | 8 +- optimizer-hints.md | 8 +- pd-control.md | 20 +-- sql-plan-management.md | 12 +- system-variables.md | 276 ++++++++++++++++++------------------- tikv-configuration-file.md | 12 +- 6 files changed, 168 insertions(+), 168 deletions(-) diff --git a/latency-breakdown.md b/latency-breakdown.md index 2c4d1b11d9943..3bbdd36bf8185 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -95,7 +95,7 @@ Diagram( ) ``` -ポイント獲得中、 `tidb_session_execute_duration_seconds{type="general"}`期間は次のように計算されます。 +PointGetの実行中、 `tidb_session_execute_duration_seconds{type="general"}`期間は次のように計算されます。 ```text tidb_session_execute_duration_seconds{type="general"} = @@ -321,7 +321,7 @@ Diagram( 実行フェーズでは、TiDBはメモリ内のデータを操作します。主なレイテンシーは必要なデータの読み取りに起因します。更新クエリと削除クエリの場合、TiDBはまずTiKVからデータを読み取り、次にメモリ内の行を更新または削除します。 -例外はPointGetとバッチPointGetによるロックタイム読み取り操作（ `SELECT FOR UPDATE` ）で、これは1回のリモートプロシージャコール（RPC）で読み取りとロックを実行します。 +例外はPointGetとBatch PointGetによるロックタイム読み取り操作（ `SELECT FOR UPDATE` ）で、これは1回のリモートプロシージャコール（RPC）で読み取りとロックを実行します。 ### Lock Time PointGet {#lock-time-point-get} @@ -342,7 +342,7 @@ Diagram( ) ``` -ロックタイムポイントの取得中、 `execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は次のように計算されます。 +Lock Time PointGetの実行中、 `execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は次のように計算されます。 ```text execution(clustered PK) = @@ -724,7 +724,7 @@ async write duration(async io enabled) = 非同期書き込みは次の 3 つのフェーズに分けられます。 -- 提案する +- 提案 - コミット - 適用：上記の式に`tikv_raftstore_apply_wait_time_duration_secs + tikv_raftstore_apply_log_duration_seconds`を代入する diff --git a/optimizer-hints.md b/optimizer-hints.md index 06ead2f9c9133..9909ed8a5dd1b 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -782,7 +782,7 @@ select /*+ READ_CONSISTENT_REPLICA() */ * from t; prepare stmt from 'select /*+ IGNORE_PLAN_CACHE() */ * from t where t.id = ?'; ``` -### SET_VAR(変数名=変数値) {#set_varvar_namevar_value} +### SET_VAR(VAR_NAME=VAR_VALUE) {#set_varvar_namevar_value} `SET_VAR(VAR_NAME=VAR_VALUE)`ヒントを使用すると、文の実行中にシステム変数の値を一時的に変更できます。文の実行後、現在のセッションにおけるシステム変数の値は自動的に元の値に戻ります。このヒントは、オプティマイザとエグゼキュータに関連する一部のシステム変数を変更するために使用できます。このヒントを使用して変更できるシステム変数のリストについては、 [システム変数](/system-variables.md)を参照してください。 @@ -815,7 +815,7 @@ SELECT @@MAX_EXECUTION_TIME; 1 row in set (0.00 sec) ``` -### ストレート結合() {#straight_join} +### STRAIGHT_JOIN() {#straight_join} `STRAIGHT_JOIN()`ヒントは、結合プランを生成するときに、 `FROM`句のテーブル名の順序でテーブルを結合するようにオプティマイザーに通知します。 @@ -846,7 +846,7 @@ SELECT /*+ NTH_PLAN(3) */ count(*) from t where a > 5; > > `NTH_PLAN(N)`は主にテスト用に使用されており、それ以降のバージョンとの互換性は保証されていません。このヒントは**慎重に**使用してください。 -### RESOURCE_GROUP(リソースグループ名) {#resource_groupresource_group_name} +### RESOURCE_GROUP(resource_group_name) {#resource_groupresource_group_name} `RESOURCE_GROUP(resource_group_name)`は、[リソース管理](/tidb-resource-control-ru-groups.md)でリソースを分離するために使用されます。このヒントは、指定されたリソースグループを使用して現在のステートメントを一時的に実行します。指定されたリソースグループが存在しない場合、このヒントは無視されます。 @@ -1087,7 +1087,7 @@ EXPLAIN SELECT /*+ leading(t1, t3), inl_join(t3) */ * FROM t1, t2, t3 WHERE t1.i `Can't find a proper physical plan for this query`エラーは次のシナリオで発生する可能性があります。 - クエリ自体はインデックスを順番に読み取る必要はありません。つまり、このクエリでは、ヒントを使用しない限り、オプティマイザはインデックスを順番に読み取るプランを生成しません。この場合、ヒント`ORDER_INDEX`が指定されていると、このエラーが発生します。この問題を解決するには、対応するヒント`ORDER_INDEX`を削除してください。 -- クエリは、 `NO_JOIN`関連するヒントを使用して、可能なすべての結合方法を除外します。 +- クエリは、 `NO_JOIN`に関連するヒントを使用して、可能なすべての結合方法を除外します。 ```sql CREATE TABLE t1 (a INT); diff --git a/pd-control.md b/pd-control.md index b0b9c31a1e1bb..7b75ec0d29b32 100644 --- a/pd-control.md +++ b/pd-control.md @@ -216,7 +216,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set enable-cross-table-merge true // Enable cross table merge. ``` -- `key-type` 、クラスターで使用されるキーエンコーディングの種類を指定します。サポートされているオプションは ["table", "raw", "txn"] で、デフォルト値は "table" です。 +- `key-type`はクラスターで使用されるキーエンコーディングの種類を指定します。サポートされているオプションは ["table", "raw", "txn"] で、デフォルト値は "table" です。 - クラスター内に TiDB インスタンスが存在しない場合は、 `key-type` 「raw」または「txn」になり、PD は`enable-cross-table-merge`設定に関係なくテーブル間でリージョンをマージできます。 - クラスター内にTiDBインスタンスが存在する場合、 `key-type`は 「table」である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。`key-type`が 「raw」の場合、配置ルールは機能しません。 @@ -231,19 +231,19 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set region-score-formula-version v2 ``` -- `patrol-region-interval` 、チェッカーがリージョンのヘルスステータスを検査する実行頻度を制御します。間隔が短いほど、実行頻度が高くなります。通常、調整する必要はありません。 +- `patrol-region-interval`はチェッカーがリージョンのヘルスステータスを検査する実行頻度を制御します。間隔が短いほど、実行頻度が高くなります。通常、調整する必要はありません。 ```bash config set patrol-region-interval 10ms // Set the execution frequency of the checker to 10ms ``` -- `patrol-region-worker-count` 、リージョンのヘルス状態を検査する際にチェッカーによって作成される同時実行数[オペレーター](/glossary.md#operator)を制御します。通常、この設定を調整する必要はありません。この設定項目を 1 より大きい値に設定すると、同時実行チェックが有効になります。現在、この機能は実験的であり、本番環境での使用は推奨されません。 +- `patrol-region-worker-count`はリージョンのヘルス状態を検査する際にチェッカーによって作成される同時実行数[オペレーター](/glossary.md#operator)を制御します。通常、この設定を調整する必要はありません。この設定項目を 1 より大きい値に設定すると、同時実行チェックが有効になります。現在、この機能は実験的であり、本番環境での使用は推奨されません。 ```bash config set patrol-region-worker-count 2 // Set the checker concurrency to 2 ``` -- `max-store-down-time` 、PD が切断されたストアを復元できないと判断するまでの時間を制御します。指定された時間内に PD がストアからハートビートを受信しない場合、PD は他のノードにレプリカを追加します。 +- `max-store-down-time`はPD が切断されたストアを復元できないと判断するまでの時間を制御します。指定された時間内に PD がストアからハートビートを受信しない場合、PD は他のノードにレプリカを追加します。 ```bash config set max-store-down-time 30m // Set the time within which PD receives no heartbeats and after which PD starts to add replicas to 30 minutes @@ -1107,12 +1107,12 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope scheduler config balance-hot-region-scheduler set src-tolerance-ratio 1.1 ``` -- `read-priorities` 、 `write-leader-priorities` 、 `write-peer-priorities` 、ホットリージョンスケジューリングにおいてスケジューラがどのディメンションを優先するかを制御します。設定では2つのディメンションがサポートされています。 +- `read-priorities` 、 `write-leader-priorities` 、 `write-peer-priorities`はホットリージョンスケジューリングにおいてスケジューラがどのディメンションを優先するかを制御します。設定では2つのディメンションがサポートされています。 - - `read-priorities` 、読み取りタイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`cpu` 、 `query` 、 `byte` 、 `key`です。 - - `write-leader-priorities` 、書き込みリーダータイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`query` 、 `byte` 、 `key`です。 + - `read-priorities`は読み取りタイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`cpu` 、 `query` 、 `byte` 、 `key`です。 + - `write-leader-priorities`は書き込みリーダータイプのホットリージョンをスケジューリングする際に、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`query` 、 `byte` 、 `key`です。 - - `write-peer-priorities` 、書き込みピアタイプのホットリージョンのスケジュールにおいて、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`byte`と`key`です。 + - `write-peer-priorities`は書き込みピアタイプのホットリージョンのスケジュールにおいて、スケジューラがどのディメンションを優先するかを制御します。ディメンションのオプションは`byte`と`key`です。 > **Note:** > @@ -1133,14 +1133,14 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope - `rank-formula-version`は、ホットリージョンスケジューリングで使用するスケジューラアルゴリズムのバージョンを制御します。値の選択肢は`v1`と`v2`です。デフォルト値は`v2`です。 - `v1`アルゴリズムは、TiDB v6.3.0以前のバージョンで使用されていたスケジューラ戦略です。このアルゴリズムは、主にストア間の負荷差を軽減することに重点を置いており、他のディメンションへの副作用の発生を回避します。 - - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、副作用を少なくしながら、ストアとファクタ間の公平性を向上させることに主眼を置いています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 + - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、ストア間の公平性の向上を主な目的としつつ、副作用も考慮しています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 ```bash scheduler config balance-hot-region-scheduler set rank-formula-version v2 ``` -- `enable-for-tiflash` 、 TiFlashインスタンス間のホットリージョンスケジューリングを有効にするかどうかを制御します。通常は有効です。無効にすると、 TiFlashインスタンス間のホットリージョンスケジューリングは実行されません。 +- `enable-for-tiflash`はTiFlashインスタンス間のホットリージョンスケジューリングを有効にするかどうかを制御します。通常は有効です。無効にすると、 TiFlashインスタンス間のホットリージョンスケジューリングは実行されません。 ```bash scheduler config balance-hot-region-scheduler set enable-for-tiflash true diff --git a/sql-plan-management.md b/sql-plan-management.md index c67eb76ca08b2..8ca334aae7726 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -112,7 +112,7 @@ SELECT * FROM bookshop . users WHERE balance > ? > **Note:** > -> 正規化プロセスでは、述語`IN`の`?` `...`として正規化されます。 +> 正規化プロセスでは、述語`IN`の`?`は`...`として正規化されます。 > > 例えば： > @@ -198,13 +198,13 @@ explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; 最初の`SELECT`文が実行されると、オプティマイザはGLOBALスコープのバインディングを介して`sm_join(t1, t2)`ヒントを文に追加します。`explain`の結果における実行計画の最上位ノードはMergeJoinです。2番目の`SELECT`文が実行されると、オプティマイザはGLOBALスコープのバインディングではなくSESSIONスコープのバインディングを使用し、 `hash_join(t1, t2)`ヒントを文に追加します。`explain`の結果における実行計画の最上位ノードはHashJoinです。 -各標準化SQL文には、 `CREATE BINDING`ずつ作成できるバインディングが1つだけです。同じ標準化SQL文に複数のバインディングが作成された場合、最後に作成されたバインディングが保持され、それ以前に作成されたバインディング（作成済みおよび展開済み）はすべて削除済みとしてマークされます。ただし、セッションバインディングとグローバルバインディングは共存可能であり、このロジックの影響を受けません。 +各標準化SQL文に対して、 `CREATE BINDING`で一度に作成できるバインディングは1つだけです。同じ標準化SQL文に複数のバインディングが作成された場合、最後に作成されたバインディングが保持され、それ以前に作成されたバインディング（作成済みおよび展開済み）はすべて削除済みとしてマークされます。ただし、セッションバインディングとグローバルバインディングは共存可能であり、このロジックの影響を受けません。 さらに、バインディングを作成する場合、TiDB ではセッションがデータベース コンテキスト内にあることが必要です。つまり、クライアントが接続されるか`use ${database}`が実行されるとき、データベースが指定されることになります。 正規化とヒントの削除後、元のSQL文とバインドされたSQL文のテキストは一致している必要があります。一致していない場合は、バインドは失敗します。次の例をご覧ください。 -- このバインディングは、パラメータ化とヒントの削除の前後のテキストが同じであるため、正常に作成できます`SELECT * FROM test . t WHERE a > ?` +- このバインディングは、パラメータ化とヒントの削除の前後のテキストが同じであるため、正常に作成できます：`SELECT * FROM test . t WHERE a > ?` ```sql CREATE BINDING FOR SELECT * FROM t WHERE a > 1 USING SELECT * FROM t use index (idx) WHERE a > 2 @@ -218,7 +218,7 @@ explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; > **Note:** > -> `PREPARE` `EXECUTE`およびバイナリ プロトコルで実行されるクエリの場合、 `PREPARE` / `EXECUTE`ステートメントではなく、実際のクエリ ステートメントの実行計画 バインディングを作成する必要があります。 +> `PREPARE` / `EXECUTE`およびバイナリ プロトコルで実行されるクエリの場合、 `PREPARE` / `EXECUTE`ステートメントではなく、実際のクエリ ステートメントのバインディングを作成する必要があります。 #### 履歴実行計画に従ってバインディングを作成する {#create-a-binding-according-to-a-historical-execution-plan} @@ -543,7 +543,7 @@ SHOW GLOBAL BINDINGS; `SHOW GLOBAL BINDINGS`出力では、クロスデータベースバインディングの`Default_db`フィールド値が空で、 `Original_sql`フィールドと`Bind_sql`フィールドのデータベース名は`*`として表されています。このバインディングは、特定のデータベースだけでなく、すべてのデータベースの`select * from t`クエリに適用されます。 -同じクエリに対して、クロスデータベース バインディングと標準バインディングの両方が共存できます。TiDB は、バインディングを次の順序で一致させます: SESSION スコープの標準バインディング > SESSION スコープのクロスデータベース バインディング > GLOBAL スコープの標準バインディング > GLOBAL スコープのクロスデータベース バインディング。 +同じクエリに対して、クロスデータベース バインディングと標準バインディングの両方が共存できます。TiDB は、バインディングを次の順序で一致させます: SESSION スコープの標準バインディング > SESSION スコープのクロスデータベース バインディング > GLOBAL スコープの標準バインディング > GLOBAL スコープのクロスデータベース バインディング。 作成構文を除き、クロスデータベースバインディングは標準バインディングと同じ削除構文とステータス変更構文を共有します。以下に詳細な使用例を示します。 @@ -653,7 +653,7 @@ SHOW GLOBAL BINDINGS; > > 現在、バインディングは、クエリ文によって生成された実行計画を修正するためのヒント群を生成します。これにより、同じクエリに対しては実行計画は変更されません。同じインデックスや結合アルゴリズム（HashJoinやIndexJoinなど）を使用するクエリを含むほとんどのOLTPクエリでは、TiDBはバインディング前後のプランの一貫性を保証します。ただし、ヒントの制限により、2つ以上のテーブルの結合、MPPクエリ、複雑なOLAPクエリなど、一部の複雑なクエリではプランの一貫性を保証できません。 -`PREPARE` `EXECUTE`およびバイナリ プロトコルで実行されたクエリの場合、TiDB は`PREPARE`ステートメントではなく、実際の`EXECUTE`ステートメントのバインディングを自動的にキャプチャします。 +`PREPARE` / `EXECUTE`およびバイナリ プロトコルで実行されたクエリの場合、TiDB は`PREPARE`ステートメントではなく、実際の`EXECUTE`ステートメントのバインディングを自動的にキャプチャします。 > **Note:** > diff --git a/system-variables.md b/system-variables.md index b08b1214f7020..483d7f2deacaa 100644 --- a/system-variables.md +++ b/system-variables.md @@ -250,23 +250,23 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; ### auto_increment_increment -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `1` - 範囲: `[1, 65535]` -- 列に割り当てられる`AUTO_INCREMENT`値のステップサイズと、 `AUTO_RANDOM` I​​D の割り当てルールを制御します。これは、 [`auto_increment_offset`](#auto_increment_offset)と組み合わせて使用​​されることがよくあります。 +- 列に割り当てられる`AUTO_INCREMENT`値のステップサイズと、 `AUTO_RANDOM` ID の割り当てルールを制御します。これは、 [`auto_increment_offset`](#auto_increment_offset)と組み合わせて使用されることがよくあります。 ### auto_increment_offset -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `1` - 範囲: `[1, 65535]` -- 列に割り当てる`AUTO_INCREMENT`値の初期オフセットと、 `AUTO_RANDOM` I​​D の割り当てルールを制御します。この設定は、 [`auto_increment_increment`](#auto_increment_increment)と組み合わせて使用​​されることがよくあります。例: +- 列に割り当てる`AUTO_INCREMENT`値の初期オフセットと、 `AUTO_RANDOM` ID の割り当てルールを制御します。この設定は、 [`auto_increment_increment`](#auto_increment_increment)と組み合わせて使用されることがよくあります。例: ```sql mysql> CREATE TABLE t1 (a int not null primary key auto_increment); @@ -367,7 +367,7 @@ mysql> SELECT * FROM t1; - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `utf8mb4_bin` -- この変数は、使用中のデータベースのデフォルトの照合照合順序を示します。**この変数を設定することは推奨されません**。新しいデータベースが選択されると、TiDBはこの変数の値を変更します。 +- この変数は、使用中のデータベースのデフォルトの照合順序を示します。**この変数を設定することは推奨されません**。新しいデータベースが選択されると、TiDBはこの変数の値を変更します。 ### collation_server @@ -375,11 +375,11 @@ mysql> SELECT * FROM t1; - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `utf8mb4_bin` -- データベース作成時にデフォルトで使用される照合照合順序。 +- データベース作成時にデフォルトで使用される照合順序。 ### cte_max_recursion_depth -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -477,7 +477,7 @@ mysql> SELECT * FROM t1; ### default_week_format -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -507,7 +507,7 @@ mysql> SELECT * FROM t1; ### div_precision_increment New in v8.0.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -534,7 +534,7 @@ mysql> SELECT * FROM t1; ### group_concat_max_len -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -579,7 +579,7 @@ mysql> SELECT * FROM t1; ### innodb_lock_wait_timeout -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -598,7 +598,7 @@ mysql> SELECT * FROM t1; > > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)では読み取り専用です。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -609,7 +609,7 @@ mysql> SELECT * FROM t1; ### last_insert_id -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -651,7 +651,7 @@ mysql> SELECT * FROM t1; > > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)では読み取り専用です。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `67108864` @@ -674,7 +674,7 @@ mysql> SELECT * FROM t1; ### max_execution_time -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -859,7 +859,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### rand_seed1 -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -869,7 +869,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### rand_seed2 -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -963,7 +963,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### sql_select_limit New in v4.0.2 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1041,7 +1041,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### tidb_adaptive_closest_read_threshold New in v6.3.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1073,7 +1073,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; ### tidb_allow_batch_cop New in v4.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -1081,7 +1081,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 範囲: `[0, 2]` - この変数は、TiDBがTiFlashにコプロセッサ要求を送信する方法を制御するために使用されます。この変数には以下の値があります。 - - `0` : リクエストをバッチで送信しないでください + - `0` : リクエストをバッチで送信しません - `1` :集計および結合リクエストはバッチで送信されます - `2` : すべてのコプロセッサ要求はバッチで送信されます @@ -1152,7 +1152,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > v7.6.0 より前のバージョンでは、通常の `ANALYZE` リージョンスキャンは `tidb_distsql_scan_concurrency` によって制御され、インデックス統計スキャンは `tidb_index_serial_scan_concurrency` によって制御されます。したがって、これらのバージョンで TiKV リージョンのスキャンの同時実行数を調整するには、`tidb_distsql_scan_concurrency` の値を変更することを検討してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1164,7 +1164,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_analyze_partition_concurrency -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `2` 。v7.4.0以前のバージョンでは、デフォルト値は`1`です。 @@ -1177,7 +1177,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > バージョン8.5.6以降、統計バージョン1（ `tidb_analyze_version = 1` ）は非推奨となり、今後のリリースで削除されます。 `tidb_analyze_version = 2`使用をお勧めします。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1332,7 +1332,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_backoff_lock_fast -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1342,7 +1342,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_backoff_weight -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1400,7 +1400,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_batch_pending_tiflash_count New in v6.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1410,19 +1410,19 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_broadcast_join_threshold_count New in v5.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 - デフォルト値: `10240` - 範囲: `[0, 9223372036854775807]` - 単位：行 -- 結合操作の対象がサブクエリに属する​​場合、オプティマイザはサブクエリの結果セットのサイズを推定できません。この場合、サイズは結果セットの行数によって決定されます。サブクエリの推定行数がこの変数の値より少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。そうでない場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 +- 結合操作の対象がサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できません。この場合、サイズは結果セットの行数によって決定されます。サブクエリの推定行数がこの変数の値より少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。そうでない場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 - この変数は、 [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710)が有効になった後は効果を発揮しません。 ### tidb_broadcast_join_threshold_size New in v5.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -1434,7 +1434,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_build_stats_concurrency -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1445,7 +1445,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_build_sampling_stats_concurrency New in v7.5.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1472,7 +1472,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; > > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)では読み取り専用です。 -- 範囲: セッション +- 対象範囲: セッション - クラスターに保持される: いいえ - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1496,7 +1496,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_checksum_table_concurrency -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `4` @@ -1637,7 +1637,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_current_ts -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -1767,7 +1767,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; > > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)では読み取り専用です。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1826,7 +1826,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; > - [{{{ .starter }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter) および [{{{ .essential }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential) では、この変数は読み取り専用です。 > - [{{{ .premium }}}](https://docs.pingcap.com/tidbcloud/select-cluster-tier#premium) では、この TiDB 変数の変更は `MODIFY COLUMN` DDL ジョブにのみ有効で、`ADD INDEX` DDL ジョブには影響しません。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -1851,7 +1851,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_default_string_match_selectivity New in v6.2.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -1896,7 +1896,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; ### tidb_distsql_scan_concurrency -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -1917,7 +1917,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; > > この変数は、非推奨のバッチ DML 機能に関連付けられており、データ破損を引き起こす可能性があります。そのため、バッチ DML でこの変数を有効にすることは推奨されません。代わりに、[非トランザクションDML](/non-transactional-dml.md)を使用してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -2644,7 +2644,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean @@ -2668,7 +2668,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean @@ -3092,7 +3092,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_executor_concurrency New in v5.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3348,7 +3348,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > バージョン7.1.0以降、この変数は非推奨となりました。代わりに、 [`tidb_session_plan_cache_size`](#tidb_session_plan_cache_size-new-in-v710)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3358,7 +3358,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_pre_split_regions New in v8.4.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3445,7 +3445,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > バージョン5.0以降、この変数は非推奨となりました。代わりに、[`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3479,7 +3479,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > バージョン5.0以降、この変数は非推奨となりました。代わりに、[`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3496,7 +3496,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > バージョン5.0以降、この変数は非推奨となりました。代わりに、[`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3518,7 +3518,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_idle_transaction_timeout New in v7.6.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3552,7 +3552,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_index_join_batch_size -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3564,7 +3564,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_index_join_double_read_penalty_cost_rate New in v6.6.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -3580,7 +3580,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > バージョン5.0以降、この変数は非推奨となりました。代わりに、[`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3597,7 +3597,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > バージョン5.0以降、この変数は非推奨となりました。代わりに、[`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3622,7 +3622,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_index_merge_intersection_concurrency New in v6.5.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: `-1` @@ -3632,7 +3632,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_index_lookup_size -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3648,7 +3648,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > この変数は非推奨であり、実行動作を制御しなくなりました。シーケンシャルインデックススキャンの同時実行数は現在 [`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50) によって制御され、[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) はインデックス統計スキャンの同時実行数を制御するために [`tidb_analyze_distsql_scan_concurrency`](#tidb_analyze_distsql_scan_concurrency-new-in-v760) を使用します。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3659,7 +3659,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_init_chunk_size -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3752,7 +3752,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `"1s"` @@ -3764,7 +3764,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `"1s"` @@ -3857,7 +3857,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_max_bytes_before_tiflash_external_group_by New in v7.0.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3885,7 +3885,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_max_bytes_before_tiflash_external_join New in v7.0.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3913,7 +3913,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_max_bytes_before_tiflash_external_sort New in v7.0.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3941,7 +3941,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_max_chunk_size -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3962,7 +3962,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_max_dist_task_nodes New in v8.5.6 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -3978,7 +3978,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_max_paging_size New in v6.3.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -3989,7 +3989,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_max_tiflash_threads New in v6.1.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -4043,7 +4043,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_mem_quota_apply_cache New in v5.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -4067,7 +4067,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_mem_quota_query -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -4162,7 +4162,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_merge_join_concurrency -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -4194,7 +4194,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > この TiDB 変数はTiDB Cloudには適用されません。 -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `60` @@ -4208,7 +4208,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > この TiDB 変数はTiDB Cloudには適用されません。 -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `60` @@ -4218,7 +4218,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_min_paging_size New in v6.2.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -4291,7 +4291,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_broadcast_cartesian_join -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -4303,7 +4303,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_concurrency_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4313,7 +4313,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_copcpu_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4323,7 +4323,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_correlation_exp_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -4337,7 +4337,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_correlation_threshold -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4347,7 +4347,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_cpu_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4366,7 +4366,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_desc_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4376,7 +4376,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー ### tidb_opt_disk_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4513,7 +4513,7 @@ mysql> desc select count(distinct a) from test.t; -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: String @@ -4587,7 +4587,7 @@ mysql> desc select count(distinct a) from test.t; ### tidb_opt_join_reorder_threshold -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -4609,7 +4609,7 @@ mysql> desc select count(distinct a) from test.t; ### tidb_opt_limit_push_down_threshold -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -4620,7 +4620,7 @@ mysql> desc select count(distinct a) from test.t; ### tidb_opt_memory_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4639,7 +4639,7 @@ mysql> desc select count(distinct a) from test.t; ### tidb_opt_network_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4661,7 +4661,7 @@ mysql> desc select count(distinct a) from test.t; ### tidb_opt_ordering_index_selectivity_ratio New in v8.0.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい @@ -4685,7 +4685,7 @@ mysql> desc select count(distinct a) from test.t; - 各例では、インデックスヒントを使用してestRowsへの影響を示しています。最終的なプランの選択は、他のプランの利用可能性とコストによって決まります。 -- 最初の例では、デフォルト値`-1`を使用しています。これは既存の見積もり式を使用します。デフォルトでは、対象となる行が見つかる前に、少数の行が見積もりの​​ためにスキャンされます。 +- 最初の例では、デフォルト値`-1`を使用しています。これは既存の見積もり式を使用します。デフォルトでは、対象となる行が見つかる前に、少数の行が見積もりのためにスキャンされます。 ```sql > SET SESSION tidb_opt_ordering_index_selectivity_ratio = -1; @@ -4777,7 +4777,7 @@ mysql> desc select count(distinct a) from test.t; ### tidb_opt_ordering_index_selectivity_threshold New in v7.0.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -4833,7 +4833,7 @@ mysql> desc select count(distinct a) from test.t; > **Note:** > - > 現在、オプティマイザはコストモデルに基づいて部分順序 TopN 最適化を適用するかどうかを動的に決定することをサポートしていません。 `USE INDEX`または`FORCE INDEX`を指定せずにこの変数を`COST`のみに設定した場合、オプティマイザはこの最適化を適用しない可能性があります。最適化が確実に適用されるようにするには、 `USE INDEX`または`FORCE INDEX`と組み合わせて使用​​してください。 + > 現在、オプティマイザはコストモデルに基づいて部分順序 TopN 最適化を適用するかどうかを動的に決定することをサポートしていません。 `USE INDEX`または`FORCE INDEX`を指定せずにこの変数を`COST`のみに設定した場合、オプティマイザはこの最適化を適用しない可能性があります。最適化が確実に適用されるようにするには、 `USE INDEX`または`FORCE INDEX`と組み合わせて使用してください。
部分順序TopN最適化の例を表示する @@ -5000,7 +5000,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; ### tidb_opt_range_max_size New in v6.4.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: `67108864` (64 MiB) @@ -5130,7 +5130,7 @@ SHOW WARNINGS; ### tidb_opt_scan_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -5140,7 +5140,7 @@ SHOW WARNINGS; ### tidb_opt_seek_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -5173,7 +5173,7 @@ SHOW WARNINGS; ### tidb_opt_tiflash_concurrency_factor -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float @@ -5207,7 +5207,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5219,7 +5219,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5231,7 +5231,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5243,7 +5243,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5255,7 +5255,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5267,7 +5267,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5279,7 +5279,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5291,7 +5291,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5303,7 +5303,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5315,7 +5315,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5327,7 +5327,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5339,7 +5339,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5351,7 +5351,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5363,7 +5363,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5375,7 +5375,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5387,7 +5387,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5399,7 +5399,7 @@ SHOW WARNINGS; > > この変数は[コストモデル](/cost-model.md)によって内部的に使用され、その値を変更することはお勧め**できません**。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Float - 範囲: `[0, 2147483647]` @@ -5407,7 +5407,7 @@ SHOW WARNINGS; ### tidb_optimizer_selectivity_level -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 - デフォルト値: `0` @@ -5483,7 +5483,7 @@ SHOW WARNINGS; ### `tidb_plan_cache_max_plan_size` New in v7.1.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値： `2097152` （2 MiB） @@ -5530,7 +5530,7 @@ SHOW WARNINGS; > > バージョン7.1.0以降、この変数は非推奨となりました。代わりに、 [`tidb_session_plan_cache_size`](#tidb_session_plan_cache_size-new-in-v710)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -5545,7 +5545,7 @@ SHOW WARNINGS; > > バージョン5.0以降、この変数は非推奨となりました。代わりに、[`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -5609,7 +5609,7 @@ SHOW WARNINGS; ### tidb_read_staleness New in v5.4.0 -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -5696,9 +5696,9 @@ SHOW WARNINGS; - `tidb_restricted_read_only`と[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)は同様の動作をします。ほとんどの場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを使用してください。 - `SUPER`または`SYSTEM_VARIABLES_ADMIN`の権限を持つユーザーは、この変数を変更できます。ただし、 [セキュリティ強化モード](#tidb_enable_enhanced_security)が有効になっている場合は、この変数を読み取りまたは変更するために、追加の`RESTRICTED_VARIABLES_ADMIN`権限が必要です。 - `tidb_restricted_read_only`は以下のケースで[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)に影響を与えます。 - - `tidb_restricted_read_only`を`ON`に設定すると、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531) `ON`に更新されます。 + - `tidb_restricted_read_only`を`ON`に設定すると、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)が`ON`に更新されます。 - `tidb_restricted_read_only`を`OFF`に設定しても、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)は変更されません。 - - `tidb_restricted_read_only`が`ON`の場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531) `OFF`に設定することはできません。 + - `tidb_restricted_read_only`が`ON`の場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)を`OFF`に設定することはできません。 - TiDB の DBaaS プロバイダーの場合、TiDB クラスタが別のデータベースのダウンストリーム データベースである場合、TiDB クラスタを読み取り専用にするには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にした上で`tidb_restricted_read_only`を使用する必要がある場合があります。これにより、顧客が[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)を使用してクラスタを書き込み可能にすることができなくなります。これを実現するには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にし、 `SYSTEM_VARIABLES_ADMIN`および`RESTRICTED_VARIABLES_ADMIN`権限を持つ管理者ユーザーを使用して`tidb_restricted_read_only`を制御し、データベース ユーザーには、 `SUPER`権限を持つルート ユーザーを使用して[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを制御させる必要があります。 - この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` 、 `SHOW` など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 - この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 @@ -5730,7 +5730,7 @@ SHOW WARNINGS; ### tidb_retry_limit -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -5744,7 +5744,7 @@ SHOW WARNINGS; > > この TiDB 変数はTiDB Cloudには適用されません。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -5883,7 +5883,7 @@ SHOW WARNINGS; ### tidb_session_plan_cache_size New in v7.1.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -5894,17 +5894,17 @@ SHOW WARNINGS; ### tidb_shard_allocate_step New in v5.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `9223372036854775807` - 範囲: `[1, 9223372036854775807]` -- この変数は、 [`AUTO_RANDOM`](/auto-random.md)または[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)属性に割り当てる連続 ID の最大数を制御します。通常、 `AUTO_RANDOM` I​​D または`SHARD_ROW_ID_BITS`注釈付き行 ID は、1 つのトランザクション内で増分され、連続しています。この変数を使用すると、大規模なトランザクションシナリオにおけるホットスポットの問題を解決できます。 +- この変数は、 [`AUTO_RANDOM`](/auto-random.md)または[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)属性に割り当てる連続 ID の最大数を制御します。通常、 `AUTO_RANDOM` ID または`SHARD_ROW_ID_BITS`注釈付き行 ID は、1 つのトランザクション内で増分され、連続しています。この変数を使用すると、大規模なトランザクションシナリオにおけるホットスポットの問題を解決できます。 ### tidb_shard_row_id_bits New in v8.4.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -5991,7 +5991,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - この変数は、TiDBノードごとに1秒あたりに書き込めるスロークエリログエントリの最大数を制御します。 - `0`という値は、1 秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 - `0`より大きい値を指定すると、TiDBは1秒あたりに指定された数のスロークエリログエントリを書き込みます。超過分のログエントリは破棄され、スロークエリログファイルには書き込まれません。 -- この変数は、高負荷条件下で過剰なスロークエリログが生成されるのを防ぐために、 [`tidb_slow_log_rules`](#tidb_slow_log_rules-new-in-v856)と組み合わせて使用​​されることが多い。 +- この変数は、高負荷条件下で過剰なスロークエリログが生成されるのを防ぐために、 [`tidb_slow_log_rules`](#tidb_slow_log_rules-new-in-v856)と組み合わせて使用されることが多い。 ### tidb_slow_log_rules New in v8.5.6 @@ -6042,7 +6042,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tidb_slow_txn_log_threshold New in v7.0.0 -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 符号なし整数 - デフォルト値: `0` @@ -6104,7 +6104,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスでは読み取り専用です。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -6337,7 +6337,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tidb_store_batch_size -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -6421,7 +6421,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tidb_tmp_table_max_size New in v5.3.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -6731,7 +6731,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tidb_txn_entry_size_limit New in v7.6.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -6801,7 +6801,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスでは読み取り専用です。 -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `300` @@ -6815,7 +6815,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > > バージョン5.0以降、この変数は非推奨となりました。代わりに、[`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50)を使用して設定してください。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -6835,7 +6835,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tiflash_fine_grained_shuffle_batch_size New in v6.2.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: `8192` - 範囲: `[1, 18446744073709551615]` @@ -6844,7 +6844,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tiflash_fine_grained_shuffle_stream_count New in v6.2.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 @@ -6859,7 +6859,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tiflash_mem_quota_query_per_node New in v7.4.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -6869,7 +6869,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tiflash_query_spill_ratio New in v7.4.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Float @@ -6923,7 +6923,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### tikv_client_read_timeout New in v7.4.0 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 @@ -6951,7 +6951,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### timestamp -- 範囲: セッション +- 対象範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Float - デフォルト値: `0` @@ -7127,7 +7127,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスでは読み取り専用です。 -- 範囲: セッション | グローバル +- 対象範囲: セッション | グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 03b1c619e8c04..731ff4c2fbcfa 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -1563,7 +1563,7 @@ Titanに関連するコンフィグレーション項目。 ### `max-background-gc` {#max-background-gc} -- TitanにおけるGCスレッドの最大数。TiKV**の詳細**>**スレッドCPU** > **RocksDB CPU**パネルで、Titan GCスレッドが長時間フル稼働状態にあることが確認された場合は、Titan GCスレッドプールのサイズを増やすことを検討してください。 +- TitanにおけるGCスレッドの最大数。TiKV**の詳細** > **スレッドCPU** > **RocksDB CPU**パネルで、Titan GCスレッドが長時間フル稼働状態にあることが確認された場合は、Titan GCスレッドプールのサイズを増やすことを検討してください。 - デフォルト値: `1` 。v8.0.0 より前のバージョンでは、デフォルト値は`4`です。 - 最小値: `1` @@ -1650,7 +1650,7 @@ Titanに関連するコンフィグレーション項目。 ### `read-amp-bytes-per-bit` {#read-amp-bytes-per-bit} - リード増幅の統計情報を有効または無効にします。 -- オプション値: `0` (無効)、> `0` (有効)。 +- オプション値: `0` (無効)、> `0` (有効)。 - デフォルト値: `0` - 最小値: `0` @@ -2196,8 +2196,8 @@ Raft Engineに関連するコンフィグレーション項目。 - Raft Engineのログ ファイルのバージョンを指定します。 - 値のオプション： - - `1` : TiKV v6.3.0 より前のバージョンのデフォルトのログファイルです。TiKV >= v6.1.0 で読み取ることができます。 - - `2` : ログのリサイクルをサポートします。TiKV >= v6.3.0 で読み取ることができます。 + - `1` : TiKV v6.3.0 より前のバージョンのデフォルトのログファイルです。TiKV >= v6.1.0 で読み取ることができます。 + - `2` : ログのリサイクルをサポートします。TiKV >= v6.3.0 で読み取ることができます。 - デフォルト値: - `storage.engine="raft-kv"`の場合、デフォルト値は`2`です。 - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 @@ -2206,7 +2206,7 @@ Raft Engineに関連するコンフィグレーション項目。 > **Note:** > -> この設定項目は、 [`format-version`](#format-version-new-in-v630) >= 2 の場合にのみ利用可能です。 +> この設定項目は、 [`format-version`](#format-version-new-in-v630) >= 2 の場合にのみ利用可能です。 - Raft Engineで古いログファイルを再利用するかどうかを決定します。有効にすると、論理的に削除されたログファイルが再利用のために予約されます。これにより、書き込みワークロードにおけるロングテールレイテンシーが軽減されます。 - デフォルト値: `true` @@ -2709,7 +2709,7 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 - タイムスタンプ要求におけるTSOの最小数。 - TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュ サイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 -- Grafana の**TiKV-RAW** > **Causal timestamp**パネルでは、 **TSO バッチ サイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカル キャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。 +- Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチ サイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカル キャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。 - デフォルト値: `100` ### `renew-batch-max-size` v6.4.0で追加 {#renew-batch-max-size-new-in-v640} From e312f7193f30d4c40dbc6e7b6410811794e03525 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 15:22:08 +0900 Subject: [PATCH 02/14] i18n(ja): fix 2 more issues found by CodeRabbit review of PR #23580 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - patrol-region-worker-count: reworded to clearly state the setting controls the NUMBER of operators run concurrently by the checker, matching EN's "controls the number of concurrent operators created by the checker" (the previous wording stacked 同時実行数 directly onto オペレーター, which read ambiguously). - max-store-down-time: changed "復元できないと判断する" (decides it cannot be restored) to "ダウンとみなす" (considers it Down), matching the canonical Down-state terminology already used consistently in tidb-scheduling.md's own description of this exact transition (Disconnect -> after max-store-down-time -> Down). Declined 2 other findings from the same review: - An info-level comment noting the repo's established three-space list-marker convention needs no change - agreed, no action needed. - A nested code-block indentation (2-space vs 4-space) nitpick in pd-control.md - EN itself has the identical indentation at this exact position, so this is a pre-existing EN-side formatting choice this PR didn't touch, not a JA-only defect. Co-Authored-By: Claude Sonnet 5 --- pd-control.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pd-control.md b/pd-control.md index 7b75ec0d29b32..d3dbe9cd7429a 100644 --- a/pd-control.md +++ b/pd-control.md @@ -237,13 +237,13 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set patrol-region-interval 10ms // Set the execution frequency of the checker to 10ms ``` -- `patrol-region-worker-count`はリージョンのヘルス状態を検査する際にチェッカーによって作成される同時実行数[オペレーター](/glossary.md#operator)を制御します。通常、この設定を調整する必要はありません。この設定項目を 1 より大きい値に設定すると、同時実行チェックが有効になります。現在、この機能は実験的であり、本番環境での使用は推奨されません。 +- `patrol-region-worker-count`は、リージョンのヘルス状態を検査する際にチェッカーが同時に実行する[オペレーター](/glossary.md#operator)の数を制御します。通常、この設定を調整する必要はありません。この設定項目を 1 より大きい値に設定すると、同時実行チェックが有効になります。現在、この機能は実験的であり、本番環境での使用は推奨されません。 ```bash config set patrol-region-worker-count 2 // Set the checker concurrency to 2 ``` -- `max-store-down-time`はPD が切断されたストアを復元できないと判断するまでの時間を制御します。指定された時間内に PD がストアからハートビートを受信しない場合、PD は他のノードにレプリカを追加します。 +- `max-store-down-time`は、PD が切断されたストアをダウンとみなすまでの時間を制御します。指定された時間内に PD がストアからハートビートを受信しない場合、PD は他のノードにレプリカを追加します。 ```bash config set max-store-down-time 30m // Set the time within which PD receives no heartbeats and after which PD starts to add replicas to 30 minutes From 0a2eed1d112cb7ba69f2688baf1fb52256864cde Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 15:32:35 +0900 Subject: [PATCH 03/14] i18n(ja): improve naturalness of "lock-time read operations" translation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ロックタイム読み取り操作 (katakana+kanji hybrid coinage) was accurate but unnatural/hard to parse at a glance. Changed to ロック取得時の 読み取り操作 ("read operation at the time of lock acquisition"), which reads as ordinary Japanese technical prose instead of an ad-hoc term, per user feedback while reading the rendered translation. Co-Authored-By: Claude Sonnet 5 --- latency-breakdown.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/latency-breakdown.md b/latency-breakdown.md index 3bbdd36bf8185..270262a5e4610 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -321,7 +321,7 @@ Diagram( 実行フェーズでは、TiDBはメモリ内のデータを操作します。主なレイテンシーは必要なデータの読み取りに起因します。更新クエリと削除クエリの場合、TiDBはまずTiKVからデータを読み取り、次にメモリ内の行を更新または削除します。 -例外はPointGetとBatch PointGetによるロックタイム読み取り操作（ `SELECT FOR UPDATE` ）で、これは1回のリモートプロシージャコール（RPC）で読み取りとロックを実行します。 +例外はPointGetとBatch PointGetによるロック取得時の読み取り操作（ `SELECT FOR UPDATE` ）で、これは1回のリモートプロシージャコール（RPC）で読み取りとロックを実行します。 ### Lock Time PointGet {#lock-time-point-get} From 672436c6eb146990e0477bfd9d5929b2658058cf Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 15:36:24 +0900 Subject: [PATCH 04/14] i18n(ja): translate "Lock Time" modifier in PointGet section headings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Also fixes an ambiguous shared-suffix construction found while reviewing the previous fix. "Lock Time PointGet" / "Lock Time Batch PointGet" (heading text, body references, and the cross-link between the two sections) renamed to "ロック取得時のPointGet" / "ロック取得時のBatch PointGet". PointGet and Batch PointGet are genuine TiDB executor/operator names shown in EXPLAIN output, so they stay in English; "Lock Time" is a plain descriptive modifier (not part of the identifier), so it reads more naturally translated, consistent with the prior fix to the generic phrase "lock-time read operations" -> ロック取得時の読み取り操作. Scoped entirely to this one file - the term has no cross-file references or links, so the anchors (#lock-time-point-get, #lock-time-batch-point-get) are left unchanged and still resolve. Also fixes: "`execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は" read ambiguously, as if 期間 (duration) applied only to the second term. Repeated 期間 after both code spans (2 occurrences, one per Lock Time [Batch] PointGet section) so both durations are unambiguously named. Co-Authored-By: Claude Sonnet 5 --- latency-breakdown.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/latency-breakdown.md b/latency-breakdown.md index 270262a5e4610..a526a02c1181b 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -323,9 +323,9 @@ Diagram( 例外はPointGetとBatch PointGetによるロック取得時の読み取り操作（ `SELECT FOR UPDATE` ）で、これは1回のリモートプロシージャコール（RPC）で読み取りとロックを実行します。 -### Lock Time PointGet {#lock-time-point-get} +### ロック取得時のPointGet {#lock-time-point-get} -以下は、Lock Time PointGet操作の時間コスト図です。 +以下は、ロック取得時のPointGet操作の時間コスト図です。 ```railroad+diagram Diagram( @@ -342,7 +342,7 @@ Diagram( ) ``` -Lock Time PointGetの実行中、 `execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は次のように計算されます。 +ロック取得時のPointGetの実行中、 `execution(clustered PK)`期間と`execution(non-clustered PK or UK)`期間は次のように計算されます。 ```text execution(clustered PK) = @@ -351,11 +351,11 @@ execution(non-clustered PK or UK) = 2 * tidb_tikvclient_txn_cmd_duration_seconds{type="lock_keys"} ``` -Lock Time PointGetはキーをロックし、その値を返します。実行後のロックフェーズと比較すると、1ラウンドトリップを節約できます。Lock Time PointGetの実行時間は[ロック期間](#lock)として扱うことができます。 +ロック取得時のPointGetはキーをロックし、その値を返します。実行後のロックフェーズと比較すると、1ラウンドトリップを節約できます。ロック取得時のPointGetの実行時間は[ロック期間](#lock)として扱うことができます。 -### Lock Time Batch PointGet {#lock-time-batch-point-get} +### ロック取得時のBatch PointGet {#lock-time-batch-point-get} -以下は、Lock Time Batch PointGet操作の時間コスト図です。 +以下は、ロック取得時のBatch PointGet操作の時間コスト図です。 ```railroad+diagram Diagram( @@ -369,7 +369,7 @@ Diagram( ) ``` -Lock Time Batch PointGetの実行中、 `execution(clustered PK)`と`execution(non-clustered PK or UK)`期間は次のように計算されます。 +ロック取得時のBatch PointGetの実行中、 `execution(clustered PK)`期間と`execution(non-clustered PK or UK)`期間は次のように計算されます。 ```text execution(clustered PK) = @@ -379,7 +379,7 @@ execution(non-clustered PK or UK) = tidb_tikvclient_txn_cmd_duration_seconds{type="lock_keys"} ``` -Lock Time Batch PointGetの実行は、1回のRPCで複数の値を読み取る点を除けば、 [Lock Time PointGet](#lock-time-point-get)と同様です。 `tidb_tikvclient_txn_cmd_duration_seconds{type="batch_get"}`所要時間の詳細については、 [Batch PointGet](#batch-point-get)セクションを参照してください。 +ロック取得時のBatch PointGetの実行は、1回のRPCで複数の値を読み取る点を除けば、 [ロック取得時のPointGet](#lock-time-point-get)と同様です。 `tidb_tikvclient_txn_cmd_duration_seconds{type="batch_get"}`所要時間の詳細については、 [Batch PointGet](#batch-point-get)セクションを参照してください。 ### ロック {#lock} From ef325433ba4bae4bf937e0036bd8e8c041c9ced4 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 15:41:09 +0900 Subject: [PATCH 05/14] =?UTF-8?q?i18n(ja):=20fix=20ambiguous=20=E3=81=AB?= =?UTF-8?q?=E3=82=88=E3=82=8A=20in=20rank-formula-version=20v2=20descripti?= =?UTF-8?q?on?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "第 1 次元の優先度均等化により重点を置いています" left it unclear whether により was the causal conjunction ("due to") or part of "に、 より" (comparative "more"), reads as a garden path. Changed to "第 1 次元の均等化をより重視しています", matching EN's "pays more attention to the priority equalization of the first dimension" unambiguously. Co-Authored-By: Claude Sonnet 5 --- pd-control.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pd-control.md b/pd-control.md index d3dbe9cd7429a..512bf269be1f3 100644 --- a/pd-control.md +++ b/pd-control.md @@ -1133,7 +1133,7 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope - `rank-formula-version`は、ホットリージョンスケジューリングで使用するスケジューラアルゴリズムのバージョンを制御します。値の選択肢は`v1`と`v2`です。デフォルト値は`v2`です。 - `v1`アルゴリズムは、TiDB v6.3.0以前のバージョンで使用されていたスケジューラ戦略です。このアルゴリズムは、主にストア間の負荷差を軽減することに重点を置いており、他のディメンションへの副作用の発生を回避します。 - - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、ストア間の公平性の向上を主な目的としつつ、副作用も考慮しています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 + - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、ストア間の公平性の向上を主な目的としつつ、副作用も考慮しています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の均等化をより重視しています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 ```bash From 50fc3bce45d1b862a9d56a701928191e8a750605 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 15:42:31 +0900 Subject: [PATCH 06/14] =?UTF-8?q?i18n(ja):=20remove=20spaces=20around=20?= =?UTF-8?q?=E7=AC=AC1=E6=AC=A1=E5=85=83/=E7=AC=AC2=E6=AC=A1=E5=85=83=20in?= =?UTF-8?q?=20pd-control.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Preemptive fix to avoid a conflict with the separate number+counter spacing sweep (PR #23578) touching the same lines. Co-Authored-By: Claude Sonnet 5 --- pd-control.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pd-control.md b/pd-control.md index 512bf269be1f3..d036149ce6a34 100644 --- a/pd-control.md +++ b/pd-control.md @@ -1133,8 +1133,8 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope - `rank-formula-version`は、ホットリージョンスケジューリングで使用するスケジューラアルゴリズムのバージョンを制御します。値の選択肢は`v1`と`v2`です。デフォルト値は`v2`です。 - `v1`アルゴリズムは、TiDB v6.3.0以前のバージョンで使用されていたスケジューラ戦略です。このアルゴリズムは、主にストア間の負荷差を軽減することに重点を置いており、他のディメンションへの副作用の発生を回避します。 - - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、ストア間の公平性の向上を主な目的としつつ、副作用も考慮しています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の均等化をより重視しています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 - - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 + - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、ストア間の公平性の向上を主な目的としつつ、副作用も考慮しています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第1次元の均等化をより重視しています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第2次元のバランスを考慮しています。 + - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第1次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 ```bash scheduler config balance-hot-region-scheduler set rank-formula-version v2 From 3d337c2d6e8f09a9730a2594d02fd2b4cdb476ad Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 15:45:20 +0900 Subject: [PATCH 07/14] =?UTF-8?q?i18n(ja):=20unify=20=E6=A8=99=E6=BA=96?= =?UTF-8?q?=E5=8C=96SQL=E6=96=87=20->=20=E6=AD=A3=E8=A6=8F=E5=8C=96?= =?UTF-8?q?=E3=81=95=E3=82=8C=E3=81=9FSQL=E6=96=87=20in=20sql-plan-managem?= =?UTF-8?q?ent.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit EN itself mixes "standardized" and "normalized" for the same concept in this file (e.g. line 203 "standardized SQL statement" vs line 398 "normalized SQL statement" for sql_digest), but this file's own JA translation already uses 正規化 16 times for the same concept (lines 103, 205, 390, etc.) and only these 4 sites (2 in one sentence, plus the 2 "Notes" bullets near the end) used the outlier 標準化. Unified to 正規化 to match this file's own dominant, more technically precise convention (TiDB's "SQL normalization" is a specific documented process, not generic standardization). Co-Authored-By: Claude Sonnet 5 --- sql-plan-management.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sql-plan-management.md b/sql-plan-management.md index 8ca334aae7726..382af9571ce49 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -198,7 +198,7 @@ explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; 最初の`SELECT`文が実行されると、オプティマイザはGLOBALスコープのバインディングを介して`sm_join(t1, t2)`ヒントを文に追加します。`explain`の結果における実行計画の最上位ノードはMergeJoinです。2番目の`SELECT`文が実行されると、オプティマイザはGLOBALスコープのバインディングではなくSESSIONスコープのバインディングを使用し、 `hash_join(t1, t2)`ヒントを文に追加します。`explain`の結果における実行計画の最上位ノードはHashJoinです。 -各標準化SQL文に対して、 `CREATE BINDING`で一度に作成できるバインディングは1つだけです。同じ標準化SQL文に複数のバインディングが作成された場合、最後に作成されたバインディングが保持され、それ以前に作成されたバインディング（作成済みおよび展開済み）はすべて削除済みとしてマークされます。ただし、セッションバインディングとグローバルバインディングは共存可能であり、このロジックの影響を受けません。 +各正規化されたSQL文に対して、 `CREATE BINDING`で一度に作成できるバインディングは1つだけです。同じ正規化されたSQL文に複数のバインディングが作成された場合、最後に作成されたバインディングが保持され、それ以前に作成されたバインディング（作成済みおよび展開済み）はすべて削除済みとしてマークされます。ただし、セッションバインディングとグローバルバインディングは共存可能であり、このロジックの影響を受けません。 さらに、バインディングを作成する場合、TiDB ではセッションがデータベース コンテキスト内にあることが必要です。つまり、クライアントが接続されるか`use ${database}`が実行されるとき、データベースが指定されることになります。 @@ -799,9 +799,9 @@ CREATE GLOBAL BINDING for SELECT * FROM t WHERE a < 100 AND b < 100 USING SELECT ベースライン進化により新しいバインディングが自動的に作成されるため、クエリ環境が変更されると、自動的に作成されたバインディングの動作が複数選択される場合があります。以下の点にご注意ください。 -- ベースライン進化では、少なくとも 1 つのグローバル バインディングを持つ標準化された SQL ステートメントのみが進化します。 +- ベースライン進化では、少なくとも 1 つのグローバル バインディングを持つ正規化された SQL ステートメントのみが進化します。 -- 新しいバインドを作成すると、以前のバインドがすべて削除されるため (標準化された SQL ステートメントの場合)、新しいバインドを手動で作成すると、自動的に進化したバインドは削除されます。 +- 新しいバインドを作成すると、以前のバインドがすべて削除されるため (正規化された SQL ステートメントの場合)、新しいバインドを手動で作成すると、自動的に進化したバインドは削除されます。 - 計算プロセスに関連するすべてのヒントは、進化の間も保持されます。これらのヒントは以下の通りです。 From 4d2a01cf1c709d8912e063d8c5cbc8c928c29c70 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 16:03:13 +0900 Subject: [PATCH 08/14] i18n(ja): clarify cross-database vs standard binding syntax comparison MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "作成構文を除き、〜同じ削除構文とステータス変更構文を共有します" was a literal calque of "Apart from X, share the same Y" that read ambiguously in Japanese. Restructured into an explicit contrast (creation syntax differs, deletion/status-change syntax is the same) per user feedback. Co-Authored-By: Claude Sonnet 5 --- sql-plan-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-plan-management.md b/sql-plan-management.md index 382af9571ce49..4f90accd8cad8 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -545,7 +545,7 @@ SHOW GLOBAL BINDINGS; 同じクエリに対して、クロスデータベース バインディングと標準バインディングの両方が共存できます。TiDB は、バインディングを次の順序で一致させます: SESSION スコープの標準バインディング > SESSION スコープのクロスデータベース バインディング > GLOBAL スコープの標準バインディング > GLOBAL スコープのクロスデータベース バインディング。 -作成構文を除き、クロスデータベースバインディングは標準バインディングと同じ削除構文とステータス変更構文を共有します。以下に詳細な使用例を示します。 +クロスデータベースバインディングの作成構文は標準バインディングと異なりますが、削除構文とステータス変更構文は同じです。以下に詳細な使用例を示します。 1. データベース`db1`と`db2`を作成し、各データベースに 2 つのテーブルを作成します。 From 3db77b8104fbebe51ae5062118ce7a47b35c89ec Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 16:06:45 +0900 Subject: [PATCH 09/14] =?UTF-8?q?i18n(ja):=20fix=20"fix"=20->=20=E5=9B=BA?= =?UTF-8?q?=E5=AE=9A=E3=81=99=E3=82=8B=20false-friend=20in=20binding=20des?= =?UTF-8?q?cription?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "generates a group of hints to fix an execution plan" was translated as 修正する ("to correct/amend"), a false friend for "fix" in the "fix in place / pin" sense. Combined with the following "実行計画は 変更されません" (does not change), this read ambiguously - as if the binding corrects the plan once and then leaves it at that corrected state, rather than pinning the plan so future executions of the same query stay consistent. Changed to 固定する (to fix/pin in place) and reworded the following clause to 変わらなくなります (becomes unchanging going forward) to make the cause-and-effect unambiguous. Co-Authored-By: Claude Sonnet 5 --- sql-plan-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-plan-management.md b/sql-plan-management.md index 4f90accd8cad8..df8468a63d1f0 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -651,7 +651,7 @@ SHOW GLOBAL BINDINGS; > **Note:** > -> 現在、バインディングは、クエリ文によって生成された実行計画を修正するためのヒント群を生成します。これにより、同じクエリに対しては実行計画は変更されません。同じインデックスや結合アルゴリズム（HashJoinやIndexJoinなど）を使用するクエリを含むほとんどのOLTPクエリでは、TiDBはバインディング前後のプランの一貫性を保証します。ただし、ヒントの制限により、2つ以上のテーブルの結合、MPPクエリ、複雑なOLAPクエリなど、一部の複雑なクエリではプランの一貫性を保証できません。 +> 現在、バインディングは、クエリ文によって生成された実行計画を固定するためのヒント群を生成します。これにより、同じクエリでは実行計画が変わらなくなります。同じインデックスや結合アルゴリズム（HashJoinやIndexJoinなど）を使用するクエリを含むほとんどのOLTPクエリでは、TiDBはバインディング前後のプランの一貫性を保証します。ただし、ヒントの制限により、2つ以上のテーブルの結合、MPPクエリ、複雑なOLAPクエリなど、一部の複雑なクエリではプランの一貫性を保証できません。 `PREPARE` / `EXECUTE`およびバイナリ プロトコルで実行されたクエリの場合、TiDB は`PREPARE`ステートメントではなく、実際の`EXECUTE`ステートメントのバインディングを自動的にキャプチャします。 From 6cbefaac04d6708bedd3bd19d5fb88d3c2e9fad7 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 16:09:03 +0900 Subject: [PATCH 10/14] =?UTF-8?q?i18n(ja):=20use=20=E3=83=90=E3=82=A4?= =?UTF-8?q?=E3=83=B3=E3=83=87=E3=82=A3=E3=83=B3=E3=82=B0=20(not=20?= =?UTF-8?q?=E3=83=90=E3=82=A4=E3=83=B3=E3=83=89)=20for=20the=20noun=20"bin?= =?UTF-8?q?ding"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This file distinguishes the EN verb "bind" (バインドする/される) from the EN noun "binding" (バインディング), but this line used the verb stem バインド as a noun 4 times where EN uses the noun "binding" 4 times ("creating a new binding deletes all previous bindings ..."). Fixed on this already-touched line; other any similar noun-usage outliers elsewhere in the file are out of scope for this PR. Co-Authored-By: Claude Sonnet 5 --- sql-plan-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-plan-management.md b/sql-plan-management.md index df8468a63d1f0..14d2c36b96e3b 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -801,7 +801,7 @@ CREATE GLOBAL BINDING for SELECT * FROM t WHERE a < 100 AND b < 100 USING SELECT - ベースライン進化では、少なくとも 1 つのグローバル バインディングを持つ正規化された SQL ステートメントのみが進化します。 -- 新しいバインドを作成すると、以前のバインドがすべて削除されるため (正規化された SQL ステートメントの場合)、新しいバインドを手動で作成すると、自動的に進化したバインドは削除されます。 +- 新しいバインディングを作成すると、以前のバインディングがすべて削除されるため (正規化された SQL ステートメントの場合)、新しいバインディングを手動で作成すると、自動的に進化したバインディングは削除されます。 - 計算プロセスに関連するすべてのヒントは、進化の間も保持されます。これらのヒントは以下の通りです。 From 28cefe32299f799414a0e0cb994bdf509da7c340 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 16:11:36 +0900 Subject: [PATCH 11/14] =?UTF-8?q?i18n(ja):=20sweep=20remaining=20=E3=83=90?= =?UTF-8?q?=E3=82=A4=E3=83=B3=E3=83=89->=E3=83=90=E3=82=A4=E3=83=B3?= =?UTF-8?q?=E3=83=87=E3=82=A3=E3=83=B3=E3=82=B0=20noun-usage=20outliers?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow-up to 6cbefaac0. Full-file scan for standalone バインド (noun) not part of バインディング, cross-checked against EN word choice at each site. 9 more sites fixed where EN uses the noun "binding" (binding creation, remove/delete a binding, retain the binding, the binding fails, applied to the created binding) but JA had the verb stem used as a noun instead - including one heading (#### SQL文に従ってバインドを削除する -> バインディングを削除する) that was inconsistent with its own parent heading (### バインディングを削除する) two lines above it. Left untouched: all verb-form uses (バインドします/バインドする/ バインドされた/バインド可能, matching EN's verb "bind"/adjective "bound"), and バインド値 (bind values), which EN itself calls "bind values" as a distinct fixed term, not "binding values". Co-Authored-By: Claude Sonnet 5 --- sql-plan-management.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/sql-plan-management.md b/sql-plan-management.md index 14d2c36b96e3b..f5bdc5a584de8 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -48,7 +48,7 @@ CREATE GLOBAL BINDING FOR SELECT * FROM orders USING SELECT /*+ use_index(orders > > バインディングは手動で追加されたヒントよりも優先されます。そのため、対応するバインディングが存在する状態でヒントを含む文を実行すると、オプティマイザの動作を制御するヒントは有効になりません。ただし、他の種類のヒントは引き続き有効です。 -具体的には、これらのステートメントのうち2種類は、構文の競合のため実行計画にバインドできません。バインドの作成時に構文エラーが報告されます。次の例をご覧ください。 +具体的には、これらのステートメントのうち2種類は、構文の競合のため実行計画にバインドできません。バインディングの作成時に構文エラーが報告されます。次の例をご覧ください。 ```sql -- Type one: Statements that get the Cartesian product by using the `JOIN` keyword and not specifying the associated columns with the `USING` keyword. @@ -202,7 +202,7 @@ explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; さらに、バインディングを作成する場合、TiDB ではセッションがデータベース コンテキスト内にあることが必要です。つまり、クライアントが接続されるか`use ${database}`が実行されるとき、データベースが指定されることになります。 -正規化とヒントの削除後、元のSQL文とバインドされたSQL文のテキストは一致している必要があります。一致していない場合は、バインドは失敗します。次の例をご覧ください。 +正規化とヒントの削除後、元のSQL文とバインドされたSQL文のテキストは一致している必要があります。一致していない場合は、バインディングは失敗します。次の例をご覧ください。 - このバインディングは、パラメータ化とヒントの削除の前後のテキストが同じであるため、正常に作成できます：`SELECT * FROM test . t WHERE a > ?` @@ -227,7 +227,7 @@ SQL文の実行計画を過去の実行計画に固定するには、Plan Digest この機能を使用する場合、次の点に注意してください。 - この機能は、過去の実行計画に基づいてヒントを生成し、生成されたヒントをバインディングに使用します。過去の実行計画は[ステートメントサマリーテーブル](/statement-summary-tables.md)に保存されるため、この機能を使用する前に、 [`tidb_enable_stmt_summary`](/system-variables.md#tidb_enable_stmt_summary-new-in-v304)システム変数を有効にする必要があります。 -- TiFlashクエリ、3つ以上のテーブルを含む結合クエリ、およびサブクエリを含むクエリの場合、自動生成されるヒントが適切ではないため、プランが完全にバインドされない可能性があります。このような場合、バインドの作成時に警告が表示されます。 +- TiFlashクエリ、3つ以上のテーブルを含む結合クエリ、およびサブクエリを含むクエリの場合、自動生成されるヒントが適切ではないため、プランが完全にバインドされない可能性があります。このような場合、バインディングの作成時に警告が表示されます。 - 履歴実行計画がヒント付きのSQL文用である場合、ヒントはバインディングに追加されます。例えば、 `SELECT /*+ max_execution_time(1000) */ * FROM t`を実行した後、そのプランダイジェストで作成されたバインディングには`max_execution_time(1000)`が含まれます。 このバインディング メソッドの SQL ステートメントは次のとおりです。 @@ -236,7 +236,7 @@ SQL文の実行計画を過去の実行計画に固定するには、Plan Digest CREATE [GLOBAL | SESSION] BINDING FROM HISTORY USING PLAN DIGEST StringLiteralOrUserVariableList; ``` -上記の文は、プランダイジェストを使用して実行計画をSQL文にバインドします。デフォルトのスコープはSESSIONです。作成されたバインドに適用されるSQL文、優先順位、スコープ、および有効条件は、 [SQL文に従って作成されたバインディング](#create-a-binding-according-to-a-sql-statement)と同じです。 +上記の文は、プランダイジェストを使用して実行計画をSQL文にバインドします。デフォルトのスコープはSESSIONです。作成されたバインディングに適用されるSQL文、優先順位、スコープ、および有効条件は、 [SQL文に従って作成されたバインディング](#create-a-binding-according-to-a-sql-statement)と同じです。 このバインディング方法を使用するには、まず`statements_summary`で対象の履歴実行計画に対応するプランダイジェストを取得し、それを使用してバインディングを作成する必要があります。詳細な手順は以下のとおりです。 @@ -308,15 +308,15 @@ SELECT @@LAST_PLAN_FROM_BINDING; ### バインディングを削除する {#remove-a-binding} -SQL ステートメントまたは SQL ダイジェストに従ってバインドを削除できます。 +SQL ステートメントまたは SQL ダイジェストに従ってバインディングを削除できます。 -#### SQL文に従ってバインドを削除する {#remove-a-binding-according-to-a-sql-statement} +#### SQL文に従ってバインディングを削除する {#remove-a-binding-according-to-a-sql-statement} ```sql DROP [GLOBAL | SESSION] BINDING FOR BindableStmt; ``` -このステートメントは、GLOBAL レベルまたは SESSION レベルで指定された実行計画のバインドを削除します。デフォルトのスコープは SESSION です。 +このステートメントは、GLOBAL レベルまたは SESSION レベルで指定された実行計画のバインディングを削除します。デフォルトのスコープは SESSION です。 一般的に、SESSIONスコープ内のバインディングは、主にテストや特殊な状況で使用されます。バインディングをすべてのTiDBプロセスで有効にするには、GLOBALバインディングを使用する必要があります。作成されたSESSIONバインディングは、セッションが終了する前にSESSIONバインディングが削除された場合でも、対応するGLOBALバインディングをSESSIONの終了まで保護します。この場合、バインディングは有効にならず、オプティマイザによってプランが選択されます。 @@ -334,7 +334,7 @@ explain SELECT * FROM t1,t2 WHERE t1.id = t2.id; #### SQLダイジェストに従ってバインディングを削除する {#remove-a-binding-according-to-sql-digest} -SQL文に従ってバインドを削除するだけでなく、SQLダイジェストに従ってバインドを削除することもできます。詳細と例については、 [`DROP [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-drop-binding.md)を参照してください。 +SQL文に従ってバインディングを削除するだけでなく、SQLダイジェストに従ってバインディングを削除することもできます。詳細と例については、 [`DROP [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-drop-binding.md)を参照してください。 ```sql DROP [GLOBAL | SESSION] BINDING FOR SQL DIGEST StringLiteralOrUserVariableList; @@ -726,7 +726,7 @@ TiDB クラスターをアップグレードする前に、次の手順を実行 - 実行計画に一貫性がある場合は、バインディングを安全に削除できます。 - - 実行計画に矛盾がある場合は、統計情報を確認するなどして原因を特定する必要があります。この場合、プランの一貫性を確保するために、バインドを保持する必要があります。 + - 実行計画に矛盾がある場合は、統計情報を確認するなどして原因を特定する必要があります。この場合、プランの一貫性を確保するために、バインディングを保持する必要があります。 ## ベースライン進化 {#baseline-evolution} From cb248e96c16d3f95a2a0735fcbcd20f86d533ad4 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 16:14:23 +0900 Subject: [PATCH 12/14] i18n(ja): clarify "the binding fails" means binding creation fails MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "バインディングは失敗します" (the binding fails) read ambiguously, as if an existing binding fails at runtime, when the actual meaning (in context of the CREATE BINDING workflow this paragraph describes) is that the binding creation attempt fails. Added の作成 for clarity, per user feedback. Co-Authored-By: Claude Sonnet 5 --- sql-plan-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-plan-management.md b/sql-plan-management.md index f5bdc5a584de8..ac33e40b9f926 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -202,7 +202,7 @@ explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; さらに、バインディングを作成する場合、TiDB ではセッションがデータベース コンテキスト内にあることが必要です。つまり、クライアントが接続されるか`use ${database}`が実行されるとき、データベースが指定されることになります。 -正規化とヒントの削除後、元のSQL文とバインドされたSQL文のテキストは一致している必要があります。一致していない場合は、バインディングは失敗します。次の例をご覧ください。 +正規化とヒントの削除後、元のSQL文とバインドされたSQL文のテキストは一致している必要があります。一致していない場合は、バインディングの作成は失敗します。次の例をご覧ください。 - このバインディングは、パラメータ化とヒントの削除の前後のテキストが同じであるため、正常に作成できます：`SELECT * FROM test . t WHERE a > ?` From a101ffd694aa56f9f3b4217bafe6daf13c390f38 Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 16:28:21 +0900 Subject: [PATCH 13/14] =?UTF-8?q?i18n(ja):=20fix=20=E3=81=A0=E4=BD=93/?= =?UTF-8?q?=E3=81=A7=E3=81=99=E4=BD=93=20style=20mixing=20in=20tidb=5Fslow?= =?UTF-8?q?=5Flog=5Fmax=5Fper=5Fsec?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "...使用されることが多い。" ended in plain/da-style, inconsistent with every surrounding bullet in this variable's description (and the file overall), which use です/ます polite style. Changed to "...多いです。". Co-Authored-By: Claude Sonnet 5 --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index 483d7f2deacaa..0c4f45f554caf 100644 --- a/system-variables.md +++ b/system-variables.md @@ -5991,7 +5991,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - この変数は、TiDBノードごとに1秒あたりに書き込めるスロークエリログエントリの最大数を制御します。 - `0`という値は、1 秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 - `0`より大きい値を指定すると、TiDBは1秒あたりに指定された数のスロークエリログエントリを書き込みます。超過分のログエントリは破棄され、スロークエリログファイルには書き込まれません。 -- この変数は、高負荷条件下で過剰なスロークエリログが生成されるのを防ぐために、 [`tidb_slow_log_rules`](#tidb_slow_log_rules-new-in-v856)と組み合わせて使用されることが多い。 +- この変数は、高負荷条件下で過剰なスロークエリログが生成されるのを防ぐために、 [`tidb_slow_log_rules`](#tidb_slow_log_rules-new-in-v856)と組み合わせて使用されることが多いです。 ### tidb_slow_log_rules New in v8.5.6 From 5385acee307105aa472805d0a820b060a7f7492d Mon Sep 17 00:00:00 2001 From: test Date: Thu, 20 Aug 2026 16:31:51 +0900 Subject: [PATCH 14/14] =?UTF-8?q?i18n(ja):=20extend=20=E3=83=90=E3=82=A4?= =?UTF-8?q?=E3=83=B3=E3=83=89->=E3=83=90=E3=82=A4=E3=83=B3=E3=83=87?= =?UTF-8?q?=E3=82=A3=E3=83=B3=E3=82=B0=20noun-usage=20fix=20to=20DROP=20BI?= =?UTF-8?q?NDING=20doc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow-up to the sql-plan-management.md sweep (28cefe322). Checked every other file mentioning バインディング/バインド corpus-wide for the same defect class (verb stem バインド used as a noun where EN says "a binding"/"bindings"). Found and fixed 4 more sites in sql-statements/sql-statement-drop-binding.md, matching EN's "You can remove a binding..." / "remove a binding according to...". Checked and confirmed clean or unrelated (different "binding" concept, e.g. binding a USER to a resource group): sql-statement-create-binding.md, sql-statement-show-bindings.md, glossary.md, statement-summary-tables.md, identify-slow-queries.md, tidb-resource-control-ru-groups.md and other resource-group docs. Co-Authored-By: Claude Sonnet 5 --- sql-statements/sql-statement-drop-binding.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sql-statements/sql-statement-drop-binding.md b/sql-statements/sql-statement-drop-binding.md index fb115d3a55479..83fb91e2a18b2 100644 --- a/sql-statements/sql-statement-drop-binding.md +++ b/sql-statements/sql-statement-drop-binding.md @@ -31,14 +31,14 @@ StringLiteralOrUserVariable ::= ## 例 {#examples} -SQL ステートメントまたは SQL ダイジェストに従ってバインドを削除できます。 +SQL ステートメントまたは SQL ダイジェストに従ってバインディングを削除できます。 -SQL ダイジェストに従ってバインドを削除する場合は、対応する SQL ダイジェストを指定する必要があります。 +SQL ダイジェストに従ってバインディングを削除する場合は、対応する SQL ダイジェストを指定する必要があります。 - プラン ダイジェストを指定するには、文字列リテラルまたは文字列型のユーザー変数のいずれかを使用できます。 - 複数の文字列値を指定し、各文字列に複数のダイジェストを含めることができます。文字列またはダイジェストはカンマで区切る必要があることに注意してください。 -次の例は、SQL ステートメントに従ってバインドを削除する方法を示しています。 +次の例は、SQL ステートメントに従ってバインディングを削除する方法を示しています。 ```sql mysql> CREATE TABLE t1 ( @@ -143,7 +143,7 @@ mysql> SHOW SESSION BINDINGS\G Empty set (0.00 sec) ``` -次の例は、SQL ダイジェストに従ってバインドを削除する方法を示しています。 +次の例は、SQL ダイジェストに従ってバインディングを削除する方法を示しています。 ```sql CREATE TABLE t1(a INT, b INT, c INT, INDEX ia(a));