i18n(ja): unify "plan cache" katakana term (remove stray space) in sql-prepared-plan-cache.md

sql-prepared-plan-cache.md

@@ -56,15 +56,15 @@ 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)を介して制御できます。
 
 > **注記：**
 >
 > [`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サーバーの未使用メモリが一定のしきい値を下回ると、
 
 <CustomContent platform="tidb-cloud">
 
-メモリ制限により、プラン キャッシュが失われる場合があります。
+メモリ制限により、プランキャッシュが失われる場合があります。
 
 </CustomContent>
 
 ## 実行プランのキャッシュをクリアする {#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
 
 <CustomContent platform="tidb-cloud">
 
-[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 秒あたりにプランキャッシュを使用している、またはプランキャッシュがないクエリの数を取得できます。
 
 </CustomContent>