i18n(ja): standardize prepared plan cache and prepared statement terminology

TOC-tidb-cloud-premium.md

@@ -98,8 +98,8 @@
           - [クエリの最適化](/agg-distinct-optimization.md)
           - [コストモデル](/cost-model.md)
           - [ランタイムフィルタ](/runtime-filter.md)
-        - [準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md)
-        - [未準備実行プランキャッシュ](/sql-non-prepared-plan-cache.md)
+        - [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)
+        - [非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)
       - 実行計画の制御
         - [概要](/control-execution-plan.md)
         - [オプティマイザのヒント](/optimizer-hints.md)

TOC-tidb-cloud-starter.md

@@ -99,8 +99,8 @@
           - [クエリの最適化](/agg-distinct-optimization.md)
           - [コストモデル](/cost-model.md)
           - [ランタイムフィルタ](/runtime-filter.md)
-        - [準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md)
-        - [未準備実行プランキャッシュ](/sql-non-prepared-plan-cache.md)
+        - [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)
+        - [非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)
       - 実行計画の制御
         - [概要](/control-execution-plan.md)
         - [オプティマイザのヒント](/optimizer-hints.md)

TOC-tidb-cloud.md

@@ -114,8 +114,8 @@
           - [クエリの最適化](/agg-distinct-optimization.md)
           - [コストモデル](/cost-model.md)
           - [ランタイムフィルタ](/runtime-filter.md)
-        - [準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md)
-        - [未準備実行プランキャッシュ](/sql-non-prepared-plan-cache.md)
+        - [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)
+        - [非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)
       - 実行計画の制御
         - [概要](/control-execution-plan.md)
         - [オプティマイザのヒント](/optimizer-hints.md)

benchmark/benchmark-tidb-using-sysbench.md

@@ -19,7 +19,7 @@ server_configs:
     log.level: "error"
 ```
 
-また、 [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)有効になっていることを確認し、 `--db-ps-mode=auto`使用して sysbench が準備済みステートメントを使用できるようにすることをお勧めします。SQL プランキャッシュの機能と監視方法については、 [SQL 準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md)のドキュメントを参照してください。
+また、 [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)が有効になっていることを確認し、 `--db-ps-mode=auto`を使用して sysbench がプリペアドステートメントを使用できるようにすることをお勧めします。SQL プランキャッシュの機能と監視方法については、 [SQL プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)のドキュメントを参照してください。
 
 > **注記：**
 >

benchmark/v3.0-performance-benchmarking-with-sysbench.md

@@ -86,7 +86,7 @@ sysbench $testname \
 
 ### TiDBパラメータ設定 {#tidb-parameter-configuration}
 
-TiDB v2.1 と v3.0 の両方で準備されたプラン キャッシュを有効にします (最適化の理由により、 `point select`と`read write` v2.1 では有効になっていません)。
+TiDB v2.1 と v3.0 の両方でプリペアドプランキャッシュを有効にします (最適化の理由により、 `point select`と`read write` v2.1 では有効になっていません)。
 
 ```toml
 [prepared-plan-cache]

develop/dev-guide-connection-parameters.md

@@ -197,7 +197,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提
     -   TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。
     -   リクエストで`COM_QUERY` `COM_STMT_EXECUTE`または`COM_STMT_PREPARE`に置き換えられている場合、この設定は既に有効になっていることを意味します。
 
--   **キャッシュ準備ステートメント**
+-   **`cachePrepStmts`**
 
     `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`設定した後、 `cachePrepStmts=true`設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。
 

develop/dev-guide-insert-data.md

@@ -82,9 +82,9 @@ MySQL JDBCDriverのデフォルト設定では、一括挿入のパフォーマ
 |            パラメータ           |                手段                |                                                                    推奨シナリオ                                                                   |          推奨コンフィグレーション         |
 | :------------------------: | :------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------: |
 |    `useServerPrepStmts`    | サーバー側を使用してプリペアドステートメントを有効にするかどうか |                                                         プリペアドステートメントを複数回使用する必要がある場合                                                         |             `true`            |
-|      `cachePrepStmts`      |  クライアントが準備済みステートメントをキャッシュするかどうか  |                                                          `useServerPrepStmts=true`                                                          |             `true`            |
+|      `cachePrepStmts`      |  クライアントがプリペアドステートメントをキャッシュするかどうか  |                                                          `useServerPrepStmts=true`                                                          |             `true`            |
 |   `prepStmtCacheSqlLimit`  |  プリペアドステートメントの最大サイズ（デフォルトは256文字） |                                                           プリペアドステートメントが256文字を超える場合                                                          | プリペアドステートメントの実際のサイズに応じて構成されます |
-|     `prepStmtCacheSize`    |  プリペアドステートメントキャッシュの最大数（デフォルトは25） |                                                           準備されたステートメントの数が25を超える場合                                                           |   準備済みステートメントの実際の数に応じて構成されます  |
+|     `prepStmtCacheSize`    |  プリペアドステートメントキャッシュの最大数（デフォルトは25） |                                                           プリペアドステートメントの数が25を超える場合                                                           |   プリペアドステートメントの実際の数に応じて構成されます  |
 | `rewriteBatchedStatements` |     **バッチ**ステートメントを書き換えるかどうか     |                                                                 バッチ処理が必要な場合                                                                 |             `true`            |
 |     `allowMultiQueries`    |            バッチ操作を開始します           | [クライアントのバグ](https://bugs.mysql.com/bug.php?id=96623)により`rewriteBatchedStatements = true`および`useServerPrepStmts = true`の場合にこれを設定する必要があるためです。 |             `true`            |
 

develop/dev-guide-prepared-statement.md

@@ -1,6 +1,6 @@
 ---
 title: プリペアドステートメント
-summary: TiDB 準備済みステートメントの使用方法について学習します。
+summary: TiDB プリペアドステートメントの使用方法について学習します。
 aliases: ['/ja/tidb/stable/dev-guide-prepared-statement/','/ja/tidbcloud/dev-guide-prepared-statement/']
 ---
 
@@ -61,7 +61,7 @@ DEALLOCATE PREPARE {prepared_statement_name};
 
 ## 例 {#examples}
 
-このセクションでは、準備されたステートメントの`SELECT`データと`INSERT`データの 2 つの例について説明します。
+このセクションでは、プリペアドステートメントの例として、データの`SELECT`とデータの`INSERT`の 2 つを説明します。
 
 ### <code>SELECT</code>例 {#code-select-code-example}
 
@@ -187,14 +187,14 @@ try (Connection connection = ds.getConnection()) {
 
 ご覧のとおり、JDBC はプリペアドステートメントのライフサイクルを制御するのに役立ち、アプリケーション内でプリペアドステートメントを手動で作成、使用、または削除する必要はありません。ただし、TiDB は MySQL と互換性があるため、クライアント側で MySQL JDBCDriverを使用する場合のデフォルト設定では、***サーバー側***プリペアドステートメントオプションが有効にならず、クライアント側プリペアドステートメントが使用されることに注意してください。
 
-次の構成は、JDBC で TiDB サーバー側の準備済みステートメントを使用するのに役立ちます。
+次の構成は、JDBC で TiDB サーバー側のプリペアドステートメントを使用するのに役立ちます。
 
 |          パラメータ          |                 手段                 |            推奨シナリオ           |          推奨コンフィグレーション         |
 | :---------------------: | :--------------------------------: | :-------------------------: | :---------------------------: |
-|   `useServerPrepStmts`  |   サーバー側を使用して準備済みステートメントを有効にするかどうか  | プリペアドステートメントを複数回使用する必要がある場合 |             `true`            |
-|     `cachePrepStmts`    |   クライアントが準備されたステートメントをキャッシュするかどうか  |  `useServerPrepStmts=true`  |             `true`            |
+|   `useServerPrepStmts`  |   サーバー側を使用してプリペアドステートメントを有効にするかどうか  | プリペアドステートメントを複数回使用する必要がある場合 |             `true`            |
+|     `cachePrepStmts`    |   クライアントがプリペアドステートメントをキャッシュするかどうか  |  `useServerPrepStmts=true`  |             `true`            |
 | `prepStmtCacheSqlLimit` | プリペアドステートメントの最大サイズ（デフォルトでは 256 文字） |   プリペアドステートメントが256文字を超える場合  | プリペアドステートメントの実際のサイズに応じて構成されます |
-|   `prepStmtCacheSize`   |    準備されたステートメントの最大数（デフォルトでは 25）    |      準備された文の数が25を超える場合      |  準備されたステートメントの実際の数に応じて構成されます  |
+|   `prepStmtCacheSize`   |    プリペアドステートメントの最大数（デフォルトでは 25）    |      プリペアドステートメントの数が25を超える場合      |  プリペアドステートメントの実際の数に応じて構成されます  |
 
 以下は、JDBC接続文字列構成の一般的なシナリオです。ホスト: `127.0.0.1` 、ポート: `4000` 、ユーザー名: `root` 、パスワード: null、デフォルトデータベース: `test` :
 

develop/java-app-best-practices.md

@@ -317,7 +317,7 @@ MyBatis Mapperは2つのパラメータをサポートしています。
 
 このマッパーは`insert on duplicate key update`ステートメントを生成します。 `(?,?,?)`に続く「値」の数は、渡されたリストの数によって決まります。最終的な効果は`rewriteBatchStatements=true`を使用した場合と同様で、クライアントと TiDB 間の通信オーバーヘッドを効果的に削減します。
 
-前述のとおり、準備済みステートメントの最大長が`prepStmtCacheSqlLimit`の値を超えると、キャッシュされないことにも注意する必要があります。
+前述のとおり、プリペアドステートメントの最大長が`prepStmtCacheSqlLimit`の値を超えると、キャッシュされないことにも注意する必要があります。
 
 #### ストリーミング結果 {#streaming-result}
 
@@ -347,9 +347,9 @@ Cursor<Post> queryAllPost();
 
 `ExecutorType`の間に { `openSession` } を選択できます。MyBatis は 3 種類の実行エンジンをサポートしています。
 
--   シンプル：プリペアドステートメントは、実行ごとにJDBCに呼び出されます（JDBC構成項目`cachePrepStmts`が有効になっている場合、繰り返し実行されるプリペアドステートメントは再利用されます）。
--   再利用: 準備済みステートメントは`executor`にキャッシュされるため、JDBC `cachePrepStmts`を使用せずに準備済みステートメントの重複呼び出しを減らすことができます。
--   バッチ: 各更新操作 ( `INSERT` / `DELETE` / `UPDATE` ) は、まずバッチに追加され、トランザクションがコミットされるか`SELECT`クエリが実行されるまで実行されます。JDBCレイヤーで`rewriteBatchStatements`が有効になっている場合は、ステートメントの書き換えが試みられます。そうでない場合は、ステートメントは 1 つずつ送信されます。
+-   Simple: プリペアドステートメントは、実行ごとにJDBCに呼び出されます（JDBC構成項目`cachePrepStmts`が有効になっている場合、繰り返し実行されるプリペアドステートメントは再利用されます）。
+-   Reuse: プリペアドステートメントは`executor`にキャッシュされるため、JDBC `cachePrepStmts`を使用せずにプリペアドステートメントの重複呼び出しを減らすことができます。
+-   Batch: 各更新操作 ( `INSERT` / `DELETE` / `UPDATE` ) は、まずバッチに追加され、トランザクションがコミットされるか`SELECT`クエリが実行されるまで実行されます。JDBCレイヤーで`rewriteBatchStatements`が有効になっている場合は、ステートメントの書き換えが試みられます。そうでない場合は、ステートメントは 1 つずつ送信されます。
 
 通常、 `ExecutorType`のデフォルト値は`Simple`です。 `ExecutorType`を呼び出すときは`openSession` } を変更する必要があります。バッチ実行の場合、トランザクション内で`UPDATE`または`INSERT`ステートメントの実行は非常に高速ですが、データの読み取りやトランザクションのコミットは遅くなる場合があります。これは正常な動作ですので、SQL クエリの遅延をトラブルシューティングする際には、この点に注意してください。
 

functions-and-operators/tidb-functions.md

@@ -489,7 +489,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1;
     -   整数フィールドのみの一意インデックスを分散させるために使用できます。
     -   複合インデックスでは効果がない可能性があります。
     -   FastPlan プロセスを実行できないため、オプティマイザーのパフォーマンスに影響します。
-    -   実行プラン キャッシュの準備には使用できません。
+    -   プリペアドプランキャッシュには使用できません。
 
 次の例は、 `TIDB_SHARD()`関数の使用方法を示しています。
 

grafana-tidb-dashboard.md

@@ -47,7 +47,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す
 -   切断数: 各 TiDB インスタンスから切断されたクライアントの数
 -   イベント OPM: 「開始」、「終了」、「正常シャットダウン」、「強制終了」、「ハング」などの主要なイベントの統計
 -   Goroutine 数: 各 TiDB インスタンス上の Goroutine の数
--   準備ステートメント数: 各 TiDB インスタンスで実行される`Prepare`のステートメントの数とその合計数
+-   プリペアドステートメント数: 各 TiDB インスタンスで実行される`Prepare`のステートメントの数とその合計数
 -   Keep Alive OPM: 各TiDBインスタンスで毎分メトリクスが更新される回数。通常は注意する必要はありません。
 -   パニックと重大なエラー: TiDB で発生したパニックと重大なエラーの数
 -   Time Jump Back OPS: 各 TiDB インスタンスでオペレーティングシステムが毎秒巻き戻す回数

latency-breakdown.md

@@ -64,7 +64,7 @@ e2e duration =
 
 -   `tidb_server_get_token_duration_seconds`トークンの待機時間を記録します。これは通常1ミリ秒未満であり、無視できるほど小さい値です。
 -   `tidb_session_parse_duration_seconds` SQL クエリを抽象構文ツリー (AST) に解析する時間を記録します。これは[`PREPARE/EXECUTE`ステートメント](/develop/dev-guide-optimize-sql-best-practices.md#use-prepare)でスキップできます。
--   `tidb_session_compile_duration_seconds` AST を実行プランにコンパイルする時間を記録し、これは[SQL 準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md)でスキップできます。
+-   `tidb_session_compile_duration_seconds` AST を実行プランにコンパイルする時間を記録し、これは[SQL プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)でスキップできます。
 -   `tidb_session_execute_duration_seconds{type="general"}`実行時間を記録しますが、これにはあらゆる種類のユーザークエリが混在します。パフォーマンスの問題やボトルネックを分析するには、これを細分化した期間に分割する必要があります。
 
 一般的に、OLTP（オンライントランザクション処理）ワークロードは、重要なコードを共有する読み取りクエリと書き込みクエリに分けられます。以下のセクションでは、実行方法が異なる[読み取りクエリ](#read-queries)と[クエリを書く](#write-queries)のレイテンシーについて説明します。