From 0995966698ff9da0af5646093760244f17641eb6 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 16 Jul 2026 16:35:50 +0900 Subject: [PATCH 1/2] =?UTF-8?q?i18n(ja):=20unify=20=E3=83=97=E3=83=A9?= =?UTF-8?q?=E3=83=B3=E3=82=AD=E3=83=A3=E3=83=83=E3=82=B7=E3=83=A5=20termin?= =?UTF-8?q?ology=20in=20sql-prepared-plan-cache.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The file mixed プラン キャッシュ (with a space) and プランキャッシュ (no space) for the same term. Normalizes all 10 spaced occurrences to the no-space form already used in the other 25 places in the file (and the repo-wide convention). The grammatically distinct プランのキャッシュ (4 occurrences) and the English "Plan Cache" (in metric names) are intentionally left unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) --- sql-prepared-plan-cache.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ee8dce525a4f1..98fbccfbe5901 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -56,7 +56,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで - 実行プランは、キャッシュされているかどうかに関わらず、SQLバインディングの影響を受けます。キャッシュされていない実行プラン（最初の`Execute` ）は、既存のSQLバインディングの影響を受けます。キャッシュされている実行プランは、新しいSQLバインディングが作成されると無効になります。 - キャッシュされたプランは、統計、最適化ルール、式によるブロックリストのプッシュダウンの変更の影響を受けません。 - `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2 つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行プランを生成しません。 -- キャッシュの無効化と削除を考慮しない場合、実行プラン キャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行プランが生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行プランを生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プラン キャッシュがあるため、以前に生成された`IndexScan`使用して実行されます。そのため、実行プラン キャッシュは、クエリが単純 (コンパイル率が高い) で実行プランが比較的固定されているアプリケーション シナリオに適しています。 +- キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行プランが生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行プランを生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プランキャッシュがあるため、以前に生成された`IndexScan`使用して実行されます。そのため、実行プランキャッシュは、クエリが単純 (コンパイル率が高い) で実行プランが比較的固定されているアプリケーション シナリオに適しています。 バージョン6.1.0以降、実行プランキャッシュはデフォルトで有効になっています。プリペアドプランキャッシュはシステム変数[`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)を介して制御できます。 @@ -64,7 +64,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで > > [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)システム変数は、 `Prepare` / `Execute`クエリの実行プランキャッシュのみを制御し、通常のクエリは制御しません。通常のクエリの実行プランキャッシュについては、 [SQL 非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)参照してください。 -実行プラン キャッシュ機能を有効にすると、セッション レベルのシステム変数[`last_plan_from_cache`](/system-variables.md#last_plan_from_cache-new-in-v40)使用して、前の`Execute`ステートメントがキャッシュされた実行プランを使用したかどうかを確認できます。次に例を示します。 +実行プランキャッシュ機能を有効にすると、セッション レベルのシステム変数[`last_plan_from_cache`](/system-variables.md#last_plan_from_cache-new-in-v40)使用して、前の`Execute`ステートメントがキャッシュされた実行プランを使用したかどうかを確認できます。次に例を示します。 ```sql MySQL [test]> create table t(a int); @@ -220,7 +220,7 @@ LIMIT 10; バージョン7.1.0以降では、システム変数[`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-new-in-v710)を使用して、キャッシュできるプランの最大サイズを制御できます。デフォルト値は2 MBです。プランのサイズがこの値を超える場合、プランはキャッシュされません。 -TiDBサーバーの未使用メモリが一定のしきい値を下回ると、プラン キャッシュのメモリ保護メカニズムがトリガーされ、キャッシュされたプランの一部が削除されます。 +TiDBサーバーの未使用メモリが一定のしきい値を下回ると、プランキャッシュのメモリ保護メカニズムがトリガーされ、キャッシュされたプランの一部が削除されます。 システム変数`tidb_prepared_plan_cache_memory_guard_ratio`設定することで、しきい値を制御できます。しきい値はデフォルトで 0.1 に設定されており、TiDBサーバーの未使用メモリが総メモリの 10% 未満（メモリの 90% が使用済み）になると、メモリ保護メカニズムが起動します。 @@ -232,17 +232,17 @@ TiDBサーバーの未使用メモリが一定のしきい値を下回ると、 -メモリ制限により、プラン キャッシュが失われる場合があります。 +メモリ制限により、プランキャッシュが失われる場合があります。 ## 実行プランのキャッシュをクリアする {#clear-execution-plan-cache} -`ADMIN FLUSH [SESSION | INSTANCE] PLAN_CACHE`ステートメントを実行すると、実行プラン キャッシュをクリアできます。 +`ADMIN FLUSH [SESSION | INSTANCE] PLAN_CACHE`ステートメントを実行すると、実行プランキャッシュをクリアできます。 このステートメントでは、 `[SESSION | INSTANCE]`プランキャッシュを現在のセッションに対してクリアするか、TiDB インスタンス全体に対してクリアするかを指定します。スコープが指定されていない場合、上記のステートメントはデフォルトで`SESSION`キャッシュに適用されます。 -以下は、 `SESSION`実行プラン キャッシュをクリアする例です。 +以下は、 `SESSION`実行プランキャッシュをクリアする例です。 ```sql MySQL [test]> create table t (a int); @@ -354,6 +354,6 @@ TiDBページの**Executor**セクションの[Grafanaダッシュボード](/gr -[TiDB Cloudコンソール](https://tidbcloud.com/)の[**監視**](/tidb-cloud/built-in-monitoring.md)ページ目で`Queries Using Plan Cache OPS`メトリックをチェックして、すべての TiDB インスタンスで 1 秒あたりにプラン キャッシュを使用している、またはプラン キャッシュがないクエリの数を取得できます。 +[TiDB Cloudコンソール](https://tidbcloud.com/)の[**監視**](/tidb-cloud/built-in-monitoring.md)ページ目で`Queries Using Plan Cache OPS`メトリックをチェックして、すべての TiDB インスタンスで 1 秒あたりにプランキャッシュを使用している、またはプランキャッシュがないクエリの数を取得できます。 From a28b5961afdf4da3fb5e2249bd384ea9ae6652d1 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 21 Jul 2026 10:43:16 +0900 Subject: [PATCH 2/2] i18n(ja): harmonize lines shared with sibling i18n PRs These lines are also touched by other open ja PRs. Each PR previously applied only its own fix, so whichever merged second would conflict. Apply the union of the fixes so every branch produces identical text and merges cleanly in any order. Co-Authored-By: Claude Opus 4.8 (1M context) --- sql-prepared-plan-cache.md | 6 +++--- sql-statements/sql-statement-admin-checksum-table.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 98fbccfbe5901..7eb631b8ac091 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -56,7 +56,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで - 実行プランは、キャッシュされているかどうかに関わらず、SQLバインディングの影響を受けます。キャッシュされていない実行プラン（最初の`Execute` ）は、既存のSQLバインディングの影響を受けます。キャッシュされている実行プランは、新しいSQLバインディングが作成されると無効になります。 - キャッシュされたプランは、統計、最適化ルール、式によるブロックリストのプッシュダウンの変更の影響を受けません。 - `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2 つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行プランを生成しません。 -- キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行プランが生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行プランを生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プランキャッシュがあるため、以前に生成された`IndexScan`使用して実行されます。そのため、実行プランキャッシュは、クエリが単純 (コンパイル率が高い) で実行プランが比較的固定されているアプリケーション シナリオに適しています。 +- キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行プランが生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行プランを生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プランキャッシュがあるため、以前に生成された`IndexScan`を使用して実行されます。そのため、実行プランキャッシュは、クエリが単純 (コンパイル率が高い) で実行プランが比較的固定されているアプリケーション シナリオに適しています。 バージョン6.1.0以降、実行プランキャッシュはデフォルトで有効になっています。プリペアドプランキャッシュはシステム変数[`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)を介して制御できます。 @@ -64,7 +64,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで > > [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)システム変数は、 `Prepare` / `Execute`クエリの実行プランキャッシュのみを制御し、通常のクエリは制御しません。通常のクエリの実行プランキャッシュについては、 [SQL 非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)参照してください。 -実行プランキャッシュ機能を有効にすると、セッション レベルのシステム変数[`last_plan_from_cache`](/system-variables.md#last_plan_from_cache-new-in-v40)使用して、前の`Execute`ステートメントがキャッシュされた実行プランを使用したかどうかを確認できます。次に例を示します。 +実行プランキャッシュ機能を有効にすると、セッション レベルのシステム変数[`last_plan_from_cache`](/system-variables.md#last_plan_from_cache-new-in-v40)を使用して、前の`Execute`ステートメントがキャッシュされた実行プランを使用したかどうかを確認できます。次に例を示します。 ```sql MySQL [test]> create table t(a int); @@ -354,6 +354,6 @@ TiDBページの**Executor**セクションの[Grafanaダッシュボード](/gr -[TiDB Cloudコンソール](https://tidbcloud.com/)の[**監視**](/tidb-cloud/built-in-monitoring.md)ページ目で`Queries Using Plan Cache OPS`メトリックをチェックして、すべての TiDB インスタンスで 1 秒あたりにプランキャッシュを使用している、またはプランキャッシュがないクエリの数を取得できます。 +[TiDB Cloudコンソール](https://tidbcloud.com/)の[**監視**](/tidb-cloud/built-in-monitoring.md)ページで`Queries Using Plan Cache OPS`メトリックをチェックして、すべての TiDB インスタンスで 1 秒あたりにプランキャッシュを使用している、またはプランキャッシュがないクエリの数を取得できます。 diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index c4aa08b6ebed1..92cbdc502d937 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -12,7 +12,7 @@ category: reference [チェックサム](/tidb-lightning/tidb-lightning-glossary.md#checksum) 、テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。 -[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。 +[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
`が実行されます。