diff --git a/TOC-tidb-cloud-premium.md b/TOC-tidb-cloud-premium.md index 8e06b23fe1c57..2eead0ef73078 100644 --- a/TOC-tidb-cloud-premium.md +++ b/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) diff --git a/TOC-tidb-cloud-starter.md b/TOC-tidb-cloud-starter.md index 9e994df9939a5..66405ec9b2ad3 100644 --- a/TOC-tidb-cloud-starter.md +++ b/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) diff --git a/TOC-tidb-cloud.md b/TOC-tidb-cloud.md index 2a2c4c26d7e68..211f39727308e 100644 --- a/TOC-tidb-cloud.md +++ b/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) diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 7c3dfaac3a927..8ef9aca7cbb11 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/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)のドキュメントを参照してください。 > **注記：** > diff --git a/benchmark/v3.0-performance-benchmarking-with-sysbench.md b/benchmark/v3.0-performance-benchmarking-with-sysbench.md index 64483c7c6eb53..55f21bd8b17ed 100644 --- a/benchmark/v3.0-performance-benchmarking-with-sysbench.md +++ b/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] diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 09db8e9d74260..3e4cf68bccf8d 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/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`設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 diff --git a/develop/dev-guide-insert-data.md b/develop/dev-guide-insert-data.md index 14943a9262e1a..2c4fd8c134385 100644 --- a/develop/dev-guide-insert-data.md +++ b/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` | diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index abbfbde18b729..744013ef926e0 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/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 つを説明します。 ### SELECT例 {#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` : diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index 28532a5ea5b04..ab4b1a6421961 100644 --- a/develop/java-app-best-practices.md +++ b/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 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 クエリの遅延をトラブルシューティングする際には、この点に注意してください。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index ca946e4c765c7..b378fa2ec8871 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -489,7 +489,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; - 整数フィールドのみの一意インデックスを分散させるために使用できます。 - 複合インデックスでは効果がない可能性があります。 - FastPlan プロセスを実行できないため、オプティマイザーのパフォーマンスに影響します。 - - 実行プラン キャッシュの準備には使用できません。 + - プリペアドプランキャッシュには使用できません。 次の例は、 `TIDB_SHARD()`関数の使用方法を示しています。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 3c95d94c1e062..0400ea802201e 100644 --- a/grafana-tidb-dashboard.md +++ b/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 インスタンスでオペレーティングシステムが毎秒巻き戻す回数 diff --git a/latency-breakdown.md b/latency-breakdown.md index 775a48da33831..d8e370c47ea68 100644 --- a/latency-breakdown.md +++ b/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)のレイテンシーについて説明します。 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index 5695bbc88ffe9..ab5a37fa1fdde 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -30,7 +30,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `OFF` - 可能`OFF`値: `ON` -- この変数は、パーティションテーブルに対してプランキャッシュを許可するかどうかを制御します。 `ON`に設定した場合、 [パーティションテーブル](/partitioned-table.md)では[準備されたステートメントプランキャッシュ](/sql-prepared-plan-cache.md)も[非プリペアドステートメントプランキャッシュ](/sql-non-prepared-plan-cache.md)有効になりません。 +- この変数は、パーティションテーブルに対してプランキャッシュを許可するかどうかを制御します。 `ON`に設定した場合、 [パーティションテーブル](/partitioned-table.md)では[プリペアドステートメントプランキャッシュ](/sql-prepared-plan-cache.md)も[非プリペアドステートメントプランキャッシュ](/sql-non-prepared-plan-cache.md)有効になりません。 ### 44262 v6.5.3 および v7.2.0 の新機能 {#a-href-https-github-com-pingcap-tidb-issues-44262-code-44262-code-a-span-class-version-mark-new-in-v6-5-3-and-v7-2-0-span} diff --git a/optimizer-hints.md b/optimizer-hints.md index 1a0317c71bbf8..40eb6b4d39b1f 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -770,7 +770,7 @@ select /*+ READ_CONSISTENT_REPLICA() */ * from t; `IGNORE_PLAN_CACHE()`ヒントは、現在の`prepare`ステートメントを処理するときにプラン キャッシュを使用しないようにオプティマイザーに通知します。 -このヒントは、 [プランキャッシュの準備](/sql-prepared-plan-cache.md)有効な場合に、特定の種類のクエリのプラン キャッシュを一時的に無効にするために使用されます。 +このヒントは、 [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)有効な場合に、特定の種類のクエリのプラン キャッシュを一時的に無効にするために使用されます。 次の例では、 `prepare`ステートメントを実行するときにプラン キャッシュが強制的に無効になります。 diff --git a/partitioned-table.md b/partitioned-table.md index 1833a398f3fa7..fcd34a1655533 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -1834,7 +1834,7 @@ mysql> explain select /*+ TIDB_INLJ(t1, t2) */ t1.* from t1, t2 where t2.code = 例2から、 `dynamic`モードでは、クエリを実行するとIndexJoinを使用した実行プランが選択されることがわかります。 -現在、 `static`プルーニング モードは、準備済みステートメントと未準備ステートメントの両方のプラン キャッシュをサポートしていません。 +現在、 `static`プルーニング モードは、プリペアドステートメントと非プリペアドステートメントの両方のプラン キャッシュをサポートしていません。 ### 動的プルーニングモードでパーティションテーブルの統計情報を更新する {#update-statistics-of-partitioned-tables-in-dynamic-pruning-mode} diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 871dfdcde7d3d..01c62fb912b09 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -74,7 +74,7 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 - 緑: `Update`および`Commit` `Insert` DMLステートメント - 赤: `StmtPrepare` `StmtReset`含む一般的`StmtClose` SQL `StmtFetch` -- SQLフェーズ別データベース時間：SQL実行フェーズは緑色で、その他のフェーズは赤色で表示されます。緑色以外の領域が大きい場合は、実行フェーズ以外のフェーズでデータベース時間が大量に消費されていることを意味し、さらなる原因分析が必要です。よくあるシナリオとしては、準備済みのプランキャッシュが利用できないために、オレンジ色で表示されるコンパイルフェーズで大きな領域が消費されているケースが挙げられます。 +- SQLフェーズ別データベース時間：SQL実行フェーズは緑色で、その他のフェーズは赤色で表示されます。緑色以外の領域が大きい場合は、実行フェーズ以外のフェーズでデータベース時間が大量に消費されていることを意味し、さらなる原因分析が必要です。よくあるシナリオとしては、プリペアドプランキャッシュが利用できないために、オレンジ色で表示されるコンパイルフェーズで大きな領域が消費されているケースが挙げられます。 - SQL実行時間の概要：緑のメトリックは一般的なKV書き込みリクエスト（ `Prewrite`や`Commit`など）、青のメトリックは一般的なKV読み取りリクエスト（CopやGetなど）、紫のメトリックはTiFlash MPPリクエストを表します。その他の色のメトリックは、注意が必要な予期しない状況を表します。例えば、悲観的ロックKVリクエストは赤で、TSO待機は濃い茶色でマークされています。青や緑以外の領域が大きい場合、SQL実行中にボトルネックが発生していることを意味します。例： @@ -139,30 +139,30 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 ### TiDB の主要メトリクスとクラスタ リソースの使用率 {#tidb-key-metrics-and-cluster-resource-utilization} -#### 1秒あたりのクエリ数、1秒あたりのコマンド数、準備済みプランキャッシュ {#query-per-second-command-per-second-and-prepared-plan-cache} +#### 1秒あたりのクエリ数、1秒あたりのコマンド数、プリペアドプランキャッシュ {#query-per-second-command-per-second-and-prepared-plan-cache} -パフォーマンス概要の次の 3 つのパネルを確認することで、アプリケーションのワークロード タイプ、アプリケーションが TiDB と対話する方法、アプリケーションが TiDB [準備されたプランキャッシュ](/sql-prepared-plan-cache.md)最大限に活用しているかどうかを知ることができます。 +パフォーマンス概要の次の 3 つのパネルを確認することで、アプリケーションのワークロード タイプ、アプリケーションが TiDB と対話する方法、アプリケーションが TiDB [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を最大限に活用しているかどうかを知ることができます。 - QPS: Query Per Second（1秒あたりのクエリ数）の略。アプリケーションによって実行されたSQL文の数を示します。 - CPSタイプ別：Command Per Secondの略。コマンドはMySQLプロトコル固有のコマンドを示します。クエリ文は、クエリコマンドまたはプリペアドステートメントのいずれかによってTiDBに送信できます。 - プラン キャッシュ OPS を使用するクエリ: `avg-hit` 、TiDB クラスターで 1 秒あたりに実行プラン キャッシュを使用するクエリの数であり、 `avg-miss` 、TiDB クラスターで 1 秒あたりに実行プラン キャッシュを使用しないクエリの数です。 - `avg-hit + avg-miss`は`StmtExecute`に等しく、これは1秒あたりに実行される全クエリ数です。TiDBで準備済みプランキャッシュを有効にすると、以下の3つのシナリオが発生します。 + `avg-hit + avg-miss`は`StmtExecute`に等しく、これは1秒あたりに実行される全クエリ数です。TiDBでプリペアドプランキャッシュを有効にすると、以下の3つのシナリオが発生します。 - - 準備されたプランキャッシュにヒットしません。1（1秒あたりのヒット`avg-hit` ）は`avg-miss` 1秒あたりのコマンド数`StmtExecute`に相当します。考えられる理由は次のとおりです。 + - プリペアドプランキャッシュにヒットしない場合：`avg-hit`（1秒あたりのヒット数）は 0 で、`avg-miss` は 1秒あたりの`StmtExecute`コマンド数に相当します。考えられる理由は次のとおりです。 - アプリケーションはクエリ インターフェイスを使用しています。 - アプリケーションは`StmtExecute`実行ごとに`StmtClose`コマンドを呼び出すため、キャッシュされたプランはクリーンアップされます。 - - `StmtExecute`によって実行されるすべてのステートメントは[キャッシュ条件](/sql-prepared-plan-cache.md)満たさないため、実行プラン キャッシュにヒットできません。 - - 準備されたすべてのプラン キャッシュがヒットします。1 (1 秒あたりのヒット数) `avg-hit` 1 秒あたり`StmtExecute`コマンドの数に等しく、 `avg-miss` (1 秒あたりのヒットがない数) は 0 です。 - - 準備済みプランキャッシュの一部がヒットしました。1（1秒あたりのヒット数） `avg-hit` 、1秒あたりのコマンド数`StmtExecute`より少ないです。準備済みプランキャッシュには既知の制限があります。例えば、サブクエリをサポートしていないため、サブクエリを含むSQL文では準備済みプランキャッシュを使用できません。 + - `StmtExecute`によって実行されるすべてのステートメントは[キャッシュ条件](/sql-prepared-plan-cache.md)を満たさないため、実行プランキャッシュにヒットできません。 + - すべてのプリペアドプランキャッシュにヒットする場合：`avg-hit`（1秒あたりのヒット数）は 1秒あたりの`StmtExecute`コマンド数に等しく、`avg-miss`（1秒あたりのヒットしない数）は 0 です。 + - プリペアドプランキャッシュの一部にヒットする場合：`avg-hit`（1秒あたりのヒット数）は 1秒あたりの`StmtExecute`コマンド数より少ないです。プリペアドプランキャッシュには既知の制限があります。例えば、サブクエリをサポートしていないため、サブクエリを含むSQL文ではプリペアドプランキャッシュを使用できません。 **例1: TPC-Cワークロード** -TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。合計 QPS は 1 秒あたり`StmtExecute`コマンドの数に等しく、後者は Queries Using Plan Cache OPS パネルでほぼ`avg-hit`に等しくなります。理想的には、クライアントはプリペアドステートメントのオブジェクトをキャッシュします。これにより、SQL ステートメントの実行時にキャッシュされたステートメントが直接呼び出されます。すべての SQL 実行は準備済みプランキャッシュにヒットするため、実行プランを生成するために再コンパイルする必要はありません。 +TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。合計 QPS は 1 秒あたり`StmtExecute`コマンドの数に等しく、後者は Queries Using Plan Cache OPS パネルでほぼ`avg-hit`に等しくなります。理想的には、クライアントはプリペアドステートメントのオブジェクトをキャッシュします。これにより、SQL ステートメントの実行時にキャッシュされたステートメントが直接呼び出されます。すべての SQL 実行はプリペアドプランキャッシュにヒットするため、実行プランを生成するために再コンパイルする必要はありません。 ![TPC-C](/media/performance/tpcc_qps.png) -**例 2: 準備されたプラン キャッシュは読み取り専用 OLTP ワークロードのクエリ コマンドには使用できません** +**例 2: プリペアドプランキャッシュは読み取り専用 OLTP ワークロードのクエリ コマンドには使用できません** このワークロードでは、 `Commit QPS` = `Rollback QPS` = `Select QPS` 。アプリケーションは自動コミット同時実行を有効にしており、接続プールから接続がフェッチされるたびにロールバックが実行されます。その結果、これら3つの文は同じ回数実行されます。 @@ -170,29 +170,29 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 - QPSパネルの赤い太線は失敗したクエリを表し、右側のY軸は失敗したクエリの数を示しています。0以外の値は、失敗したクエリが存在することを意味します。 - 合計 QPS は、CPS By Type パネルのクエリの数と等しく、クエリ コマンドがアプリケーションによって使用されています。 -- プランキャッシュを使用するクエリOPSパネルにはデータが表示されません。これは、クエリコマンドで準備されたプランキャッシュが利用できないためです。つまり、TiDBはクエリ実行ごとに実行プランを解析して生成する必要があります。その結果、TiDBによるCPU消費量の増加に伴い、コンパイル時間が長くなります。 +- プランキャッシュを使用するクエリOPSパネルにはデータが表示されません。これは、クエリコマンドでプリペアドプランキャッシュが利用できないためです。つまり、TiDBはクエリ実行ごとに実行プランを解析して生成する必要があります。その結果、TiDBによるCPU消費量の増加に伴い、コンパイル時間が長くなります。 -**例3: OLTPワークロードに対してプリペアドステートメントが有効になっている場合、準備済みプランキャッシュは利用できません** +**例3: OLTPワークロードに対してプリペアドステートメントが有効になっている場合、プリペアドプランキャッシュは利用できません** `StmtPrepare`回 = `StmtExecute`回 = `StmtClose`回 ~= `StmtFetch`回。アプリケーションは準備 > 実行 > フェッチ > クローズのループを使用します。プリペアドステートメントオブジェクトのリークを防ぐため、多くのアプリケーションフレームワークは`execute`フェーズの後に`close`呼び出します。これにより、2つの問題が発生します。 - SQL 実行には 4 つのコマンドと 4 回のネットワーク ラウンドトリップが必要です。 -- プランキャッシュを使用するクエリのOPSは0で、準備されたプランキャッシュのヒットがゼロであることを示しています。1 `StmtClose`のコマンドはデフォルトでキャッシュされた実行プランをクリアし、次の`StmtPrepare`コマンドで実行プランを再度生成する必要があります。 +- プランキャッシュを使用するクエリのOPSは0で、プリペアドプランキャッシュのヒットがゼロであることを示しています。`StmtClose`のコマンドはデフォルトでキャッシュされた実行プランをクリアし、次の`StmtPrepare`コマンドで実行プランを再度生成する必要があります。 > **注記：** > -> TiDB v6.0.0以降では、グローバル変数（ `set global tidb_ignore_prepared_cache_close_stmt=on;` ）を介して、 `StmtClose`コマンドによるキャッシュされた実行プランのクリアを防止できます。これにより、後続の実行では準備されたプランキャッシュを利用できます。 +> TiDB v6.0.0以降では、グローバル変数（ `set global tidb_ignore_prepared_cache_close_stmt=on;` ）を介して、 `StmtClose`コマンドによるキャッシュされた実行プランのクリアを防止できます。これにより、後続の実行ではプリペアドプランキャッシュを利用できます。 ![OLTP-Prepared](/media/performance/oltp_prepared_statement_no_plan_cache.png) -**例4: 準備されたステートメントにリソースリークがある** +**例4: プリペアドステートメントにリソースリークがある** -1 秒あたり`StmtPrepare`コマンドの数は 1 秒あたり`StmtClose`コマンドの数よりはるかに多く、これはアプリケーションに準備されたステートメントのオブジェクト リークがあることを示しています。 +1 秒あたり`StmtPrepare`コマンドの数は 1 秒あたり`StmtClose`コマンドの数よりはるかに多く、これはアプリケーションにプリペアドステートメントのオブジェクト リークがあることを示しています。 ![OLTP-Query](/media/performance/prepared_statement_leaking.png) - QPSパネルでは、赤い太線が失敗したクエリの数を示し、右側のY軸がその数値の座標値を示しています。この例では、1秒あたりの失敗したクエリの数は74.6です。 -- CPS By Type パネルでは、1 秒あたり`StmtPrepare`コマンドの数が 1 秒あたり`StmtClose`コマンドの数よりはるかに多く、準備されたステートメントのアプリケーションでオブジェクト リークが発生していることを示しています。 +- CPS By Type パネルでは、1 秒あたり`StmtPrepare`コマンドの数が 1 秒あたり`StmtClose`コマンドの数よりはるかに多く、プリペアドステートメントのアプリケーションでオブジェクト リークが発生していることを示しています。 - プラン キャッシュを使用したクエリ OPS パネルでは、 `avg-miss`タイプ別 CPS パネルの`StmtExecute`とほぼ等しく、ほとんどすべての SQL 実行で実行プラン キャッシュが失われていることを示しています。 #### KV/TSO 要求 OPS とソース別の KV 要求時間 {#kv-tso-request-ops-and-kv-request-time-by-source} @@ -370,29 +370,29 @@ TiDB での SQL 処理は、 `get token` 、 `parse` 、 `compile` 、 `execute` - `get token` : 通常は数マイクロ秒程度で無視できます。トークンは、単一のTiDBインスタンスへの接続数が[トークン制限](/tidb-configuration-file.md)上限に達した場合にのみ制限されます。 - `parse` : クエリ ステートメントは抽象構文ツリー (AST) に解析されます。 -- `compile` : 実行計画は、第`parse`フェーズのASTと統計情報に基づいて作成されます。第`compile`フェーズには、論理最適化と物理最適化が含まれます。論理最適化では、リレーショナル代数に基づく列プルーニングなどのルールに従ってクエリプランを最適化します。物理最適化では、コストベースオプティマイザによって統計情報に基づいて実行計画のコストを推定し、最もコストが低い物理実行計画を選択します。 +- `compile` : 実行計画は、`parse`フェーズのASTと統計情報に基づいて作成されます。`compile`フェーズには、論理最適化と物理最適化が含まれます。論理最適化では、リレーショナル代数に基づく列プルーニングなどのルールに従ってクエリプランを最適化します。物理最適化では、コストベースオプティマイザによって統計情報に基づいて実行計画のコストを推定し、最もコストが低い物理実行計画を選択します。 - `execute` : SQL文の実行にかかる時間。TiDBはまず、グローバルに一意なタイムスタンプTSOを待機します。 `execute` 、エグゼキュータは実行プラン内のオペレータのキー範囲に基づいてTiKV APIリクエストを構築し、TiKVに配布します。2時間には、TSOの待機時間、KVリクエスト時間、およびTiDBエグゼキュータによるデータ処理時間が含まれます。 アプリケーションが`query`または`StmtExecute` MySQL コマンド インターフェイスのみを使用する場合は、次の式を使用して平均レイテンシーのボトルネックを特定できます。 avg Query Duration = avg Get Token + avg Parse Duration + avg Compile Duration + avg Execute Duration -通常、 `query`レイテンシーのうち、第`execute`フェーズが大部分を占めます。ただし、以下の場合には、第`parse`フェーズと`compile`フェーズも大きな割合を占めることがあります。 +通常、 `query`レイテンシーのうち、`execute`フェーズが大部分を占めます。ただし、以下の場合には、`parse`フェーズと`compile`フェーズも大きな割合を占めることがあります。 - フェーズ`parse`での長いレイテンシー: たとえば、ステートメント`query`が長い場合、SQL テキストを解析するために多くの CPU が消費されます。 -- 第`compile`フェーズでの長いレイテンシー：準備されたプランキャッシュにヒットしない場合、TiDBはSQL実行ごとに実行プランをコンパイルする必要があります。第`compile`フェーズのレイテンシーは数ミリ秒から数十ミリ秒、あるいはそれ以上になる場合があります。準備されたプランキャッシュにヒットしない場合、第`compile`フェーズで論理的および物理的な最適化が行われ、CPUとメモリを大量に消費し、Goランタイム（TiDBは[`Go`](https://go.dev/)で記述されています）に負担がかかり、他のTiDBコンポーネントのパフォーマンスに影響を与えます。準備されたプランキャッシュは、TiDBにおけるOLTPワークロードの効率的な処理に重要です。 +- `compile`フェーズでの長いレイテンシー：プリペアドプランキャッシュにヒットしない場合、TiDBはSQL実行ごとに実行プランをコンパイルする必要があります。`compile`フェーズのレイテンシーは数ミリ秒から数十ミリ秒、あるいはそれ以上になる場合があります。プリペアドプランキャッシュにヒットしない場合、`compile`フェーズで論理的および物理的な最適化が行われ、CPUとメモリを大量に消費し、Goランタイム（TiDBは[`Go`](https://go.dev/)で記述されています）に負担がかかり、他のTiDBコンポーネントのパフォーマンスに影響を与えます。プリペアドプランキャッシュは、TiDBにおけるOLTPワークロードの効率的な処理に重要です。 **例1: `compile`フェーズにおけるデータベースのボトルネック** ![Compile](/media/performance/long_compile.png) -上の図では、 `execute` `parse`の平均時間はそれぞれ 17.1 `compile`秒、729 マイクロ秒、681 マイクロ秒です。フェーズ`compile`レイテンシーが高いのは、アプリケーションが`query`コマンドインターフェースを使用しており、準備済みプランキャッシュを使用できないためです。 +上の図では、 `execute` `parse`の平均時間はそれぞれ 17.1 `compile`秒、729 マイクロ秒、681 マイクロ秒です。フェーズ`compile`レイテンシーが高いのは、アプリケーションが`query`コマンドインターフェースを使用しており、プリペアドプランキャッシュを使用できないためです。 **例2: `execute`フェーズにおけるデータベースのボトルネック** ![Execute](/media/performance/long_execute.png) -このTPC-Cワークロードでは、 `parse` 、 `compile` 、第`execute`フェーズの平均時間はそれぞれ7.39マイクロ秒、38.1マイクロ秒、12.8ミリ秒です。第`execute`フェーズが第`query`レイテンシーのレイテンシのボトルネックとなっています。 +このTPC-Cワークロードでは、 `parse` 、 `compile` 、`execute`フェーズの平均時間はそれぞれ7.39マイクロ秒、38.1マイクロ秒、12.8ミリ秒です。`execute`フェーズが`query`レイテンシーのレイテンシのボトルネックとなっています。 #### KVおよびTSOリクエスト期間 {#kv-and-tso-request-duration} diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 4cf3b73d8e62a..a104543980128 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -408,7 +408,7 @@ QPSは34.9kから40.9kに増加し、KVリクエストタイプはフェーズ`e | クエリ期間 | 479μs | 1120μs | 528μs | 426μs | 690μs | 533μs | 313μs | -38% | -41% | | QPS | 56.3k | 24.2k | 19.7k | 22.1k | 30.9k | 34.9k | 40.9k | +28% | +108% | -これらのシナリオでは、シナリオ 2 はアプリケーションがクエリ インターフェイスを使用する一般的なシナリオであり、シナリオ 5 はアプリケーションが準備済みステートメント インターフェイスを使用する理想的なシナリオです。 +これらのシナリオでは、シナリオ 2 はアプリケーションがクエリ インターフェイスを使用する一般的なシナリオであり、シナリオ 5 はアプリケーションがプリペアドステートメント インターフェイスを使用する理想的なシナリオです。 - シナリオ 5 とシナリオ 2 を比較すると、 Javaアプリケーション開発のベスト プラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすることで、各 SQL ステートメントで実行プラン キャッシュをヒットするために必要なコマンドとデータベース操作が 1 つだけになり、クエリのレイテンシーが 38% 短縮され、QPS が 28% 増加し、TiDB の平均 CPU 使用率が 936% から 577% に低下していることがわかります。 - シナリオ 7 とシナリオ 3 を比較すると、シナリオ 5 に RC 読み取りや小さなテーブル キャッシュなどの最新の TiDB 最適化機能を追加すると、レイテンシーが41% 削減され、QPS が 108% 増加し、平均 TiDB CPU 使用率が 936% から 478% に低下することがわかります。 diff --git a/releases/release-3.0.1.md b/releases/release-3.0.1.md index cb0551ed9bf1f..c63852d5bda86 100644 --- a/releases/release-3.0.1.md +++ b/releases/release-3.0.1.md @@ -19,7 +19,7 @@ TiDB Ansible バージョン: 3.0.1 - プラグイン`ADMIN PLUGINS DISABLE` `ADMIN PLUGINS ENABLE`ステートメントを追加する[＃11157](https://github.com/pingcap/tidb/pull/11157) - 監査プラグイン[＃11013](https://github.com/pingcap/tidb/pull/11013)にセッション接続情報を追加する - リージョン分割期間中のデフォルトの動作を変更し、PD がスケジュール[＃11166](https://github.com/pingcap/tidb/pull/11166)を完了するまで待機します。 -- 一部のケースで誤った結果を回避するために、ウィンドウ関数がプラン準備キャッシュにキャッシュされることを禁止します[＃11048](https://github.com/pingcap/tidb/pull/11048) +- 一部のケースで誤った結果を回避するために、ウィンドウ関数がプリペアドプランキャッシュにキャッシュされることを禁止します[＃11048](https://github.com/pingcap/tidb/pull/11048) - `ALTER`文が保存された生成列の定義を変更することを禁止する[＃11068](https://github.com/pingcap/tidb/pull/11068) - 仮想生成列を保存生成列に変更することを禁止する[＃11068](https://github.com/pingcap/tidb/pull/11068) - インデックス[＃11068](https://github.com/pingcap/tidb/pull/11068)で生成された列式の変更を禁止する diff --git a/releases/release-5.0.2.md b/releases/release-5.0.2.md index e87932146d3bf..05853491be91d 100644 --- a/releases/release-5.0.2.md +++ b/releases/release-5.0.2.md @@ -65,7 +65,7 @@ TiDB バージョン: 5.0.2 - TiDB - 一部のケースでプレフィックスインデックスとインデックス結合を使用することで発生するpanic問題を修正[＃24547](https://github.com/pingcap/tidb/issues/24547) [＃24716](https://github.com/pingcap/tidb/issues/24716) [＃24717](https://github.com/pingcap/tidb/issues/24717) - - `point get`の準備されたプランキャッシュがトランザクション[＃24741](https://github.com/pingcap/tidb/issues/24741)の`point get`文によって誤って使用される問題を修正しました。 + - `point get`のプリペアドプランキャッシュがトランザクションの`point get`文によって誤って使用される問題を修正しました[＃24741](https://github.com/pingcap/tidb/issues/24741)。 - 照合順序が`ascii_bin`または`latin1_bin`場合に間違ったプレフィックスインデックス値を書き込む問題を修正しました[＃24569](https://github.com/pingcap/tidb/issues/24569) - GCワーカー[＃24591](https://github.com/pingcap/tidb/issues/24591)によって進行中のトランザクションが中断される可能性がある問題を修正 - `new-collation`が有効で`new-row-format`無効の場合、クラスター化インデックスでポイントクエリが間違って実行される可能性があるバグを修正しました[＃24541](https://github.com/pingcap/tidb/issues/24541) diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index f960580330cca..698979635ef1b 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -272,7 +272,7 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - ユーザーが`INSERT`操作を実行するには、テーブルに対する`DELETE`権限と`REPLACE`権限の両方が必要になりました [#24070](https://github.com/pingcap/tidb/pull/24070) - バイナリとバイトの比較ミスによって発生した誤った`TableDual`プランを修正 [#23846](https://github.com/pingcap/tidb/issues/23846) - プレフィックスインデックスとインデックス結合の使用によって発生するpanic問題を修正[#24547](https://github.com/pingcap/tidb/issues/24547) [#24716](https://github.com/pingcap/tidb/issues/24716) [#24717](https://github.com/pingcap/tidb/issues/24717) - - トランザクションにおいて、 `point get` ステートメントが `point get` の準備済みプランキャッシュを誤って使用する問題を修正します。 [#24741](https://github.com/pingcap/tidb/issues/24741) + - トランザクションにおいて、 `point get` ステートメントが `point get` のプリペアドプランキャッシュを誤って使用する問題を修正します。 [#24741](https://github.com/pingcap/tidb/issues/24741) - 照合順序が`ascii_bin`または`latin1_bin`の場合に、誤ったプレフィックスインデックス値が書き込まれる問題を修正しました [#24569](https://github.com/pingcap/tidb/issues/24569) - 進行中のトランザクションがGCワーカーによって中断される可能性がある問題を修正しました [#24591](https://github.com/pingcap/tidb/issues/24591) - `new-collation`が有効で`new-row-format`が無効になっている場合に、クラスター化インデックスでポイントクエリが正しく実行されない可能性があるバグを修正しました [#24541](https://github.com/pingcap/tidb/issues/24541) diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md index 33059120cff82..19c10d90ea4bb 100644 --- a/releases/release-5.4.3.md +++ b/releases/release-5.4.3.md @@ -48,7 +48,7 @@ TiDB バージョン: 5.4.3 - UPDATE文が場合によっては投影を誤って削除し、 `Can't find column`エラー[＃37568](https://github.com/pingcap/tidb/issues/37568)が発生する問題を修正しました。 - パーティションテーブルがインデックスを完全に使用してデータをスキャンできない場合がある問題を修正[＃33966](https://github.com/pingcap/tidb/issues/33966) - 特定のシナリオ[＃37187](https://github.com/pingcap/tidb/issues/37187)予期しないエラーが発生する可能性がある問題を修正しました`EXECUTE` - - 準備済みプランキャッシュが有効になっている`BIT`タイプのインデックスを使用すると、TiDBが間違った結果を返す可能性がある問題を修正しました[＃33067](https://github.com/pingcap/tidb/issues/33067) + - プリペアドプランキャッシュが有効になっている`BIT`タイプのインデックスを使用すると、TiDBが間違った結果を返す可能性がある問題を修正しました[＃33067](https://github.com/pingcap/tidb/issues/33067) - TiKV diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 0c2c556c8335a..8a45b7aec7361 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.0.0-DMR - クラスターのパフォーマンス データを常時収集する継続的なプロファイリングをサポートし、技術専門家の MTTR を短縮します。 - ホットスポットの小さなテーブルをメモリにキャッシュすることで、アクセス パフォーマンスが大幅に向上し、スループットが向上し、アクセスレイテンシーが短縮されます。 - インメモリの悲観的ロックを最適化します。悲観的ロックによって引き起こされるパフォーマンスのボトルネックに対して、悲観的ロックのメモリ最適化により、レイテンシーを10%削減し、QPSを10%向上させることができます。 -- 実行プランを共有するように準備されたステートメントを強化することで、CPU リソースの消費が軽減され、SQL 実行の効率が向上します。 +- 実行プランを共有するようにプリペアドステートメントを強化することで、CPU リソースの消費が軽減され、SQL 実行の効率が向上します。 - より多くの式のプッシュダウンとエラスティック スレッド プールの一般提供 (GA) をサポートすることで、MPP エンジンのコンピューティング パフォーマンスが向上します。 - 多数の移行タスクの管理を容易にするためにDM WebUI を追加します。 - 大規模クラスターでデータを複製する際の TiCDC の安定性と効率性が向上しました。TiCDC は現在、100,000 個のテーブルの同時複製をサポートしています。 @@ -104,9 +104,9 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 [ユーザードキュメント](/transaction-isolation-levels.md#read-committed-isolation-level) [＃33159](https://github.com/pingcap/tidb/issues/33159) -- 実行プランを共有するために準備されたステートメントを強化する +- 実行プランを共有するためにプリペアドステートメントを強化する - SQL 実行プランを再利用すると、SQL 文の解析時間を効果的に短縮し、CPU リソースの消費を抑え、SQL 実行効率を向上させることができます。SQL チューニングの重要な方法の 1 つは、SQL 実行プランを効果的に再利用することです。TiDB は、準備済みステートメントと実行プランの共有をサポートしています。ただし、準備済みステートメントが閉じられると、TiDB は対応するプラン キャッシュを自動的にクリアします。その後、TiDB は繰り返される SQL 文を不必要に解析し、実行効率に影響を与える可能性があります。v6.0.0 以降、TiDB は`tidb_ignore_prepared_cache_close_stmt`パラメータ (デフォルトでは無効) によって`COM_STMT_CLOSE`のコマンドを無視するかどうかを制御できるようになりました。パラメータを有効にすると、TiDB は準備済みステートメントを閉じるコマンドを無視し、実行プランをキャッシュに保持するため、実行プランの再利用率が向上します。 + SQL 実行プランを再利用すると、SQL 文の解析時間を効果的に短縮し、CPU リソースの消費を抑え、SQL 実行効率を向上させることができます。SQL チューニングの重要な方法の 1 つは、SQL 実行プランを効果的に再利用することです。TiDB は、プリペアドステートメントと実行プランの共有をサポートしています。ただし、プリペアドステートメントが閉じられると、TiDB は対応するプラン キャッシュを自動的にクリアします。その後、TiDB は繰り返される SQL 文を不必要に解析し、実行効率に影響を与える可能性があります。v6.0.0 以降、TiDB は`tidb_ignore_prepared_cache_close_stmt`パラメータ (デフォルトでは無効) によって`COM_STMT_CLOSE`のコマンドを無視するかどうかを制御できるようになりました。パラメータを有効にすると、TiDB はプリペアドステートメントを閉じるコマンドを無視し、実行プランをキャッシュに保持するため、実行プランの再利用率が向上します。 [ユーザードキュメント](/sql-prepared-plan-cache.md#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement) [＃31056](https://github.com/pingcap/tidb/issues/31056) @@ -287,7 +287,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 ### システム変数 {#system-variables} -
変数名タイプを変更説明
placement_checks削除済みDDL ステートメントがSQL の配置ルールで指定された配置ルールを検証するかどうかを制御します。tidb_placement_mode に置き換えられtidb_placement_modeた。
tidb_enable_alter_placement削除済みSQL で配置ルールを有効にするかどうかを制御します。
tidb_mem_quota_hashjoin
tidb_mem_quota_indexlookupjoin
tidb_mem_quota_indexlookupreader
tidb_mem_quota_mergejoin
tidb_mem_quota_sort
tidb_mem_quota_topn		削除済みv5.0以降、これらの変数はtidb_mem_quota_queryに置き換えられ、システム変数ドキュメントから削除されました。互換性を確保するため、これらの変数はソースコードに残されていました。TiDB 6.0.0以降、これらの変数はコードからも削除されています。
tidb_enable_mutation_checker新しく追加されたミューテーションチェッカーを有効にするかどうかを制御します。デフォルト値はONです。v6.0.0より前のバージョンからアップグレードする既存のクラスターの場合、ミューテーションチェッカーはデフォルトで無効になっています。
tidb_ignore_prepared_cache_close_stmt新しく追加された準備済みステートメントを閉じるコマンドを無視するかどうかを制御します。デフォルト値はOFFです。
tidb_mem_quota_binding_cache新しく追加されたキャッシュ保持バインディングのメモリ使用量のしきい値を設定します。デフォルト値は67108864 （64 MiB）です。
tidb_placement_mode新しく追加されたDDL文がSQLの配置ルールで指定された配置ルールを無視するかどうかを制御します。デフォルト値はstrictで、DDL文は配置ルールを無視しません。
tidb_rc_read_check_ts新しく追加された
  • トランザクション内の読み取りステートメントのレイテンシーを最適化します。読み取り/書き込みの競合が深刻な場合、この変数をオンにするとオーバーヘッドとレイテンシーが増加し、パフォーマンスが低下します。デフォルト値はoffです。
  • この変数はまだreplica-readと互換性がありません。読み取りリクエストでtidb_rc_read_check_tsがオンになっている場合、 replica-read を使用できない可能性があります。両方の変数を同時にオンにしないでください。
tidb_sysdate_is_now新しく追加されたSYSDATE関数をNOW関数に置き換えるかどうかを制御します。この設定項目は、MySQLオプションsysdate-is-nowと同じ効果があります。デフォルト値はOFFです。
tidb_table_cache_lease新しく追加されたテーブルキャッシュのリース時間を秒単位で制御します。デフォルト値は3です。
tidb_top_sql_max_meta_count新しく追加されたTop SQLによって1分間に収集されるSQL文タイプの最大数を制御します。デフォルト値は5000です。
tidb_top_sql_max_time_series_count新しく追加された負荷に最も寄与するSQL文（つまり、上位N文）を1分あたりにTop SQLで記録できる回数を制御します。デフォルト値は100です。
tidb_txn_assertion_level新しく追加されたアサーションレベルを制御します。アサーションは、データとインデックス間の整合性チェックであり、トランザクションのコミットプロセスにおいて、書き込まれるキーが存在するかどうかを確認します。デフォルトでは、ほとんどのチェック項目が有効になっており、パフォーマンスへの影響はほとんどありません。v6.0.0より前のバージョンからアップグレードした既存のクラスターでは、このチェックはデフォルトで無効になっています。
+
変数名タイプを変更説明
placement_checks削除済みDDL ステートメントがSQL の配置ルールで指定された配置ルールを検証するかどうかを制御します。tidb_placement_mode に置き換えられtidb_placement_modeた。
tidb_enable_alter_placement削除済みSQL で配置ルールを有効にするかどうかを制御します。
tidb_mem_quota_hashjoin
tidb_mem_quota_indexlookupjoin
tidb_mem_quota_indexlookupreader
tidb_mem_quota_mergejoin
tidb_mem_quota_sort
tidb_mem_quota_topn		削除済みv5.0以降、これらの変数はtidb_mem_quota_queryに置き換えられ、システム変数ドキュメントから削除されました。互換性を確保するため、これらの変数はソースコードに残されていました。TiDB 6.0.0以降、これらの変数はコードからも削除されています。
tidb_enable_mutation_checker新しく追加されたミューテーションチェッカーを有効にするかどうかを制御します。デフォルト値はONです。v6.0.0より前のバージョンからアップグレードする既存のクラスターの場合、ミューテーションチェッカーはデフォルトで無効になっています。
tidb_ignore_prepared_cache_close_stmt新しく追加されたプリペアドステートメントを閉じるコマンドを無視するかどうかを制御します。デフォルト値はOFFです。
tidb_mem_quota_binding_cache新しく追加されたキャッシュ保持バインディングのメモリ使用量のしきい値を設定します。デフォルト値は67108864 （64 MiB）です。
tidb_placement_mode新しく追加されたDDL文がSQLの配置ルールで指定された配置ルールを無視するかどうかを制御します。デフォルト値はstrictで、DDL文は配置ルールを無視しません。
tidb_rc_read_check_ts新しく追加された
  • トランザクション内の読み取りステートメントのレイテンシーを最適化します。読み取り/書き込みの競合が深刻な場合、この変数をオンにするとオーバーヘッドとレイテンシーが増加し、パフォーマンスが低下します。デフォルト値はoffです。
  • この変数はまだreplica-readと互換性がありません。読み取りリクエストでtidb_rc_read_check_tsがオンになっている場合、 replica-read を使用できない可能性があります。両方の変数を同時にオンにしないでください。
tidb_sysdate_is_now新しく追加されたSYSDATE関数をNOW関数に置き換えるかどうかを制御します。この設定項目は、MySQLオプションsysdate-is-nowと同じ効果があります。デフォルト値はOFFです。
tidb_table_cache_lease新しく追加されたテーブルキャッシュのリース時間を秒単位で制御します。デフォルト値は3です。
tidb_top_sql_max_meta_count新しく追加されたTop SQLによって1分間に収集されるSQL文タイプの最大数を制御します。デフォルト値は5000です。
tidb_top_sql_max_time_series_count新しく追加された負荷に最も寄与するSQL文（つまり、上位N文）を1分あたりにTop SQLで記録できる回数を制御します。デフォルト値は100です。
tidb_txn_assertion_level新しく追加されたアサーションレベルを制御します。アサーションは、データとインデックス間の整合性チェックであり、トランザクションのコミットプロセスにおいて、書き込まれるキーが存在するかどうかを確認します。デフォルトでは、ほとんどのチェック項目が有効になっており、パフォーマンスへの影響はほとんどありません。v6.0.0より前のバージョンからアップグレードした既存のクラスターでは、このチェックはデフォルトで無効になっています。
### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md index 78b6a5729c0b5..d16ed38bfbdcc 100644 --- a/releases/release-6.1.6.md +++ b/releases/release-6.1.6.md @@ -52,7 +52,7 @@ TiDB バージョン: 6.1.6 - 単一のSQL文に異なるパーティションテーブルが出現した場合にTiDBが誤った結果を生成する可能性がある問題を修正[＃42135](https://github.com/pingcap/tidb/issues/42135) @ [mjonss](https://github.com/mjonss) - プランキャッシュがシャッフル演算子をキャッシュし、誤った結果を返す可能性がある問題を修正[＃38335](https://github.com/pingcap/tidb/issues/38335) @ [qw4990](https://github.com/qw4990) @ [fzzf678](https://github.com/fzzf678) - インデックスマージを使用して`SET`型の列を含むテーブルを読み取ると、誤った結果[＃41293](https://github.com/pingcap/tidb/issues/41293) @ [time-and-fate](https://github.com/time-and-fate)が発生する可能性がある問題を修正しました - - 準備済みプランキャッシュが有効な場合にフルインデックススキャンでエラーが発生する可能性がある問題を修正[＃42150](https://github.com/pingcap/tidb/issues/42150) @ [fzzf678](https://github.com/fzzf678) + - プリペアドプランキャッシュが有効な場合にフルインデックススキャンでエラーが発生する可能性がある問題を修正[＃42150](https://github.com/pingcap/tidb/issues/42150) @ [fzzf678](https://github.com/fzzf678) - DDL文の実行中に`PointGet`使用してテーブルを読み込むSQL文がpanic[＃41622](https://github.com/pingcap/tidb/issues/41622) @ [tiancaiamao](https://github.com/tiancaiamao)をスローする可能性がある問題を修正しました - トランザクション内で`PointUpdate`実行した後、TiDB が`SELECT`文[＃28011](https://github.com/pingcap/tidb/issues/28011) @ [zyguan](https://github.com/zyguan)に対して誤った結果を返す問題を修正しました。 - メモリリークとパフォーマンスの低下を防ぐため、期限切れのリージョンキャッシュを定期的にクリアします[＃40461](https://github.com/pingcap/tidb/issues/40461) @ [sticnarf](https://github.com/sticnarf) @ [zyguan](https://github.com/zyguan) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index e690b7b4fc1db..97381520db94b 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -415,7 +415,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - TiDB Dashboard - - スロークエリページに 3 つの新しいフィールドを追加します:「準備済みですか?」、「プランはキャッシュからですか?」、「プランはバインディングからですか?」 [＃1451](https://github.com/pingcap/tidb-dashboard/issues/1451) @ [shhdgit](https://github.com/shhdgit) + - スロークエリページに 3 つの新しいフィールドを追加します:「Is Prepared?」、「Is Plan from Cache?」、「Is Plan from Binding?」 [＃1451](https://github.com/pingcap/tidb-dashboard/issues/1451) @ [shhdgit](https://github.com/shhdgit) - Backup & Restore (BR) diff --git a/releases/release-6.5.2.md b/releases/release-6.5.2.md index e361a6125d8ab..4a9bf40d4c460 100644 --- a/releases/release-6.5.2.md +++ b/releases/release-6.5.2.md @@ -62,8 +62,8 @@ TiDB バージョン: 6.5.2 - `INSERT IGNORE`と`REPLACE`ステートメントが値[＃42121](https://github.com/pingcap/tidb/issues/42121) @ [zyguan](https://github.com/zyguan)を変更しないキーをロックしない問題を修正しました - 実行中にTiFlash が生成された列に対してエラーを報告する問題を修正[＃40663](https://github.com/pingcap/tidb/issues/40663) @ [guo-shaoge](https://github.com/guo-shaoge) - 単一のSQL文に異なるパーティションテーブルが出現した場合にTiDBが誤った結果を生成する可能性がある問題を修正[＃42135](https://github.com/pingcap/tidb/issues/42135) @ [mjonss](https://github.com/mjonss) - - 準備済みプランキャッシュが有効な場合にフルインデックススキャンでエラーが発生する可能性がある問題を修正[＃42150](https://github.com/pingcap/tidb/issues/42150) @ [fzzf678](https://github.com/fzzf678) - - 準備プランキャッシュが有効な場合に IndexMerge が誤った結果を生成する可能性がある問題を修正[＃41828](https://github.com/pingcap/tidb/issues/41828) @ [qw4990](https://github.com/qw4990) + - プリペアドプランキャッシュが有効な場合にフルインデックススキャンでエラーが発生する可能性がある問題を修正[＃42150](https://github.com/pingcap/tidb/issues/42150) @ [fzzf678](https://github.com/fzzf678) + - プリペアドプランキャッシュが有効な場合に IndexMerge が誤った結果を生成する可能性がある問題を修正[＃41828](https://github.com/pingcap/tidb/issues/41828) @ [qw4990](https://github.com/qw4990) - `max_prepared_stmt_count`の設定が[＃39735](https://github.com/pingcap/tidb/issues/39735)で@[xuyifangreeneyes](https://github.com/xuyifangreeneyes)に反映されない問題を修正 - グローバルメモリ制御が、メモリ使用量が`tidb_server_memory_limit_sess_min_size` [＃42662](https://github.com/pingcap/tidb/issues/42662) @ [XuHuaiyu](https://github.com/XuHuaiyu)未満の SQL 文を誤って強制終了する可能性がある問題を修正しました。 - パーティションテーブル[＃40596](https://github.com/pingcap/tidb/issues/40596) @ [tiancaiamao](https://github.com/tiancaiamao)の動的トリミングモードでインデックス結合によりpanicが発生する可能性がある問題を修正しました。 diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 6d2f8d210a87e..c78438e7215b0 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -68,7 +68,7 @@ TiDB バージョン: 6.5.6 - CAST に精度損失がないのに条件`cast(col)=range`で FullScan が発生する問題を修正[＃45199](https://github.com/pingcap/tidb/issues/45199) @ [AilinKid](https://github.com/AilinKid) - `batch-client` in `client-go` [＃47691](https://github.com/pingcap/tidb/issues/47691) @ [crazycs520](https://github.com/crazycs520)のpanic問題を修正 - 非整数クラスター化インデックス[＃47350](https://github.com/pingcap/tidb/issues/47350) @ [tangenta](https://github.com/tangenta)でのテーブル分割操作を禁止する - - 時間変換[＃42439](https://github.com/pingcap/tidb/issues/42439) @ [qw4990](https://github.com/qw4990)中に準備済みプラン キャッシュと準備されていないプラン キャッシュの動作間の非互換性の問題を修正しました + - 時刻変換中にプリペアドプランキャッシュと非プリペアドプランキャッシュの動作間の非互換性の問題を修正しました[＃42439](https://github.com/pingcap/tidb/issues/42439) @ [qw4990](https://github.com/qw4990) - 取り込みモード[＃39641](https://github.com/pingcap/tidb/issues/39641) @ [tangenta](https://github.com/tangenta)を使用して空のテーブルにインデックスを作成できないことがある問題を修正しました - パーティション交換[＃46492](https://github.com/pingcap/tidb/issues/46492) @ [mjonss](https://github.com/mjonss)中にパーティション定義に準拠していないデータを検出できない問題を修正 - `GROUP_CONCAT` `ORDER BY`列[＃41986](https://github.com/pingcap/tidb/issues/41986) @ [AilinKid](https://github.com/AilinKid)を解析できない問題を修正 diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index 4e33a43e8d1e1..e093a29c23cca 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone バージョン7.0.0-DMRの主な新機能と改善点は以下のとおりです。 -
カテゴリ特徴説明
拡張性とパフォーマンス
セッションレベルの未準備SQLプランキャッシュ（実験的）セッションレベルでプランキャッシュを自動的に再利用することで、コンパイルを削減し、同じSQLパターンに対して事前に手動で準備ステートメントを設定することなくクエリ時間を短縮します。
TiFlashは 、分散型ストレージおよびコンピューティングアーキテクチャとS3共有ストレージ（実験的）をサポートしています。 TiFlashは、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlashのコンピューティング機能とストレージを分離することで、柔軟なHTAPリソース利用における画期的な進歩を実現しました。
  • S3ベースのストレージエンジンを導入し、より低コストで共有ストレージを提供可能にしました。
信頼性と可用性
リソース制御機能強化（実験的）リソースグループを使用して、1 つのクラスタ内のさまざまなアプリケーションやワークロードにリソースを割り当て、分離することをサポートします。今回のリリースでは、TiDB はさまざまなリソースバインディングモード (ユーザー、セッション、ステートメントレベル) とユーザー定義の優先度をサポートします。さらに、コマンドを使用してリソースのキャリブレーション (リソース全体の量の見積もり) を実行することもできます。
TiFlashはディスクへのスピルをサポートしていますTiFlashは、集計、ソート、ハッシュ結合などのデータ集約型操作におけるメモリ不足（OOM）を軽減するために、中間結果をディスクに書き出す機能をサポートしています。
SQL行レベルTTL （GA）一定期間経過したデータを自動的に削除することで、データベースサイズの管理をサポートし、パフォーマンスを向上させます。
LIST / RANGEパーティションを再編成するREORGANIZE PARTITIONステートメントは、隣接するパーティションをマージしたり、1 つのパーティションを複数のパーティションに分割したりするために使用でき、パーティション化されたテーブルの使いやすさを向上させます。
データベースの運用と可観測性
TiDBはLOAD DATAステートメントの機能を拡張します（実験的）。 TiDBは、S3/GCSからのデータインポートをサポートするなど、 LOAD DATA SQLステートメントの機能を拡張します。
TiCDCはオブジェクトストレージシンク（GA）をサポートしていますTiCDCは、Amazon S3、GCS、Azure Blob Storage、NFSなどのオブジェクトストレージサービスへの行変更イベントの複製をサポートしています。
+
カテゴリ特徴説明
拡張性とパフォーマンス
セッションレベルの非プリペアドSQLプランキャッシュ（実験的）セッションレベルでプランキャッシュを自動的に再利用することで、コンパイルを削減し、同じSQLパターンに対して事前に手動でプリペアドステートメントを設定することなくクエリ時間を短縮します。
TiFlashは 、分散型ストレージおよびコンピューティングアーキテクチャとS3共有ストレージ（実験的）をサポートしています。 TiFlashは、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlashのコンピューティング機能とストレージを分離することで、柔軟なHTAPリソース利用における画期的な進歩を実現しました。
  • S3ベースのストレージエンジンを導入し、より低コストで共有ストレージを提供可能にしました。
信頼性と可用性
リソース制御機能強化（実験的）リソースグループを使用して、1 つのクラスタ内のさまざまなアプリケーションやワークロードにリソースを割り当て、分離することをサポートします。今回のリリースでは、TiDB はさまざまなリソースバインディングモード (ユーザー、セッション、ステートメントレベル) とユーザー定義の優先度をサポートします。さらに、コマンドを使用してリソースのキャリブレーション (リソース全体の量の見積もり) を実行することもできます。
TiFlashはディスクへのスピルをサポートしていますTiFlashは、集計、ソート、ハッシュ結合などのデータ集約型操作におけるメモリ不足（OOM）を軽減するために、中間結果をディスクに書き出す機能をサポートしています。
SQL行レベルTTL （GA）一定期間経過したデータを自動的に削除することで、データベースサイズの管理をサポートし、パフォーマンスを向上させます。
LIST / RANGEパーティションを再編成するREORGANIZE PARTITIONステートメントは、隣接するパーティションをマージしたり、1 つのパーティションを複数のパーティションに分割したりするために使用でき、パーティション化されたテーブルの使いやすさを向上させます。
データベースの運用と可観測性
TiDBはLOAD DATAステートメントの機能を拡張します（実験的）。 TiDBは、S3/GCSからのデータインポートをサポートするなど、 LOAD DATA SQLステートメントの機能を拡張します。
TiCDCはオブジェクトストレージシンク（GA）をサポートしていますTiCDCは、Amazon S3、GCS、Azure Blob Storage、NFSなどのオブジェクトストレージサービスへの行変更イベントの複製をサポートしています。
## 機能の詳細 {#feature-details} @@ -59,11 +59,11 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone 詳細については、[ドキュメント](/tiflash/tiflash-late-materialization.md)を参照してください。 -- 準備されていないステートメントの実行プランのキャッシュをサポートする（実験的） [#36598](https://github.com/pingcap/tidb/issues/36598) @[qw4990](https://github.com/qw4990) +- 非プリペアドステートメントの実行プランのキャッシュをサポートする（実験的） [#36598](https://github.com/pingcap/tidb/issues/36598) @[qw4990](https://github.com/qw4990) - 実行プラン キャッシュは同時 OLTP の負荷容量を向上させるために重要であり、TiDB はすでに[準備された実行プランキャッシュ](/sql-prepared-plan-cache.md)キャッシュをサポートしています。 v7.0.0 では、TiDB は非 Prepare ステートメントの実行プランをキャッシュすることもできるため、実行プラン キャッシュの範囲が拡張され、TiDB の同時処理能力が向上します。 + 実行プランキャッシュは同時実行 OLTP の処理能力を向上させるために重要であり、TiDB はすでに[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)をサポートしています。 v7.0.0 では、TiDB は非 Prepare ステートメントの実行プランをキャッシュすることもできるため、実行プラン キャッシュの範囲が拡張され、TiDB の同時処理能力が向上します。 - この機能はデフォルトでは無効になっています。システム変数[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) `ON`に設定することで有効にできます。安定性のため、TiDB v7.0.0 では準備されていない実行プランをキャッシュするための新しい領域が割り当てられ、システム変数[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)を使用してキャッシュサイズを設定できます。さらに、この機能には SQL ステートメントに関する特定の制限があります。詳細については、 [制限](/sql-non-prepared-plan-cache.md#restrictions)参照してください。 + この機能はデフォルトでは無効になっています。システム変数[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) `ON`に設定することで有効にできます。安定性のため、TiDB v7.0.0 では非プリペアド実行プランをキャッシュするための新しい領域が割り当てられ、システム変数[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)を使用してキャッシュサイズを設定できます。さらに、この機能には SQL ステートメントに関する特定の制限があります。詳細については、 [制限](/sql-non-prepared-plan-cache.md#restrictions)参照してください。 詳細については、[ドキュメント](/sql-non-prepared-plan-cache.md)を参照してください。 @@ -280,10 +280,10 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone | 変数名 | 変更の種類 | 説明 | | --------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `tidb_pessimistic_txn_aggressive_locking` | 削除済み | この変数は[`tidb_pessimistic_txn_fair_locking`](/system-variables.md#tidb_pessimistic_txn_fair_locking-new-in-v700)に名前が変更されました。 | -| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | v7.0.0 から有効になり、[準備されていないプランキャッシュ](/sql-non-prepared-plan-cache.md)機能を有効にするかどうかを制御します。 | +| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | v7.0.0 から有効になり、[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)機能を有効にするかどうかを制御します。 | | [`tidb_enable_null_aware_anti_join`](/system-variables.md#tidb_enable_null_aware_anti_join-new-in-v630) | 変更 | さらなるテストの後、デフォルト値を`OFF`から`ON`に変更します。これは、特別なセット演算子`NOT IN`および`!= ALL`によってリードされるサブクエリによって Anti Join が生成される場合に、TiDB がデフォルトで Null-Aware Hash Join を適用することを意味します。 | | [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、クラスターがデフォルトでリソースグループごとにリソースを分離することを意味します。リソース制御は v7.0.0 でデフォルトで有効になっているため、いつでもこの機能を使用できます。 | -| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 変更 | v7.0.0 から有効になり、[準備されていないプランキャッシュ](/sql-non-prepared-plan-cache.md)によってキャッシュできる実行プランの最大数を制御します。 | +| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 変更 | v7.0.0 から有効になり、[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)によってキャッシュできる実行プランの最大数を制御します。 | | [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600) | 変更 | バージョン7.0.0以降、この変数はプリペアドステートメントプロトコルにおけるカーソルフェッチ読み取りには有効ではなくなりました。 | | [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-new-in-v700) | 新しく追加された | この変数は、内部テーブルに`Selection`または`Projection`演算子がある場合に、インデックス結合がサポートされるかどうかを制御します。 | | [`tidb_enable_plan_cache_for_subquery`](/system-variables.md#tidb_enable_plan_cache_for_subquery-new-in-v700) | 新しく追加された | この変数は、プリペアドプランキャッシュがサブクエリを含むクエリをキャッシュするかどうかを制御します。 | @@ -393,13 +393,13 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - インデックス追加時のpanic問題を修正 [#41880](https://github.com/pingcap/tidb/issues/41880) @[tangenta](https://github.com/tangenta) - TiFlashが実行中に生成された列に対してエラーを報告する問題を修正 [#40663](https://github.com/pingcap/tidb/issues/40663) @[guo-shaoge](https://github.com/guo-shaoge) - TiDBが時間型の場合に統計情報を正しく取得できない可能性がある問題を修正しました [#41938](https://github.com/pingcap/tidb/issues/41938) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - - 準備済みプランキャッシュが有効になっている場合に、フルインデックススキャンでエラーが発生する可能性がある問題を修正しました [#42150](https://github.com/pingcap/tidb/issues/42150) @[fzzf678](https://github.com/fzzf678) + - プリペアドプランキャッシュが有効になっている場合に、フルインデックススキャンでエラーが発生する可能性がある問題を修正しました [#42150](https://github.com/pingcap/tidb/issues/42150) @[fzzf678](https://github.com/fzzf678) - `IFNULL(NOT NULL COLUMN, ...)`が間違った結果を返す可能性がある問題を修正 [#41734](https://github.com/pingcap/tidb/issues/41734) @[LittleFall](https://github.com/LittleFall) - パーティションテーブル内のすべてのデータが単一のリージョンにある場合に、TiDBが誤った結果を生成する可能性がある問題を修正します [#41801](https://github.com/pingcap/tidb/issues/41801) @[Defined2014](https://github.com/Defined2014) - TiDB で、異なるパーティション テーブルが単一の SQL ステートメントに現れる場合に誤った結果が生成される可能性がある問題を修正しました [#42135](https://github.com/pingcap/tidb/issues/42135) @[mjonss](https://github.com/mjonss) - パーティションテーブルに新しいインデックスを追加した後、パーティションパーティションテーブルで統計情報の自動収集が正しくトリガーされない可能性がある問題を修正しました [#41638](https://github.com/pingcap/tidb/issues/41638) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - TiDBが統計情報を2回連続で収集した後に誤った列統計情報を読み取る可能性がある問題を修正 [#42073](https://github.com/pingcap/tidb/issues/42073) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - - プラン準備キャッシュが有効になっている場合に IndexMerge が誤った結果を生成する可能性がある問題を修正しました [#41828](https://github.com/pingcap/tidb/issues/41828) @[qw4990](https://github.com/qw4990) + - プリペアドプランキャッシュが有効になっている場合に IndexMerge が誤った結果を生成する可能性がある問題を修正しました [#41828](https://github.com/pingcap/tidb/issues/41828) @[qw4990](https://github.com/qw4990) - IndexMerge に goroutine リークがある可能性がある問題を修正 [#41605](https://github.com/pingcap/tidb/issues/41605) @[guo-shaoge](https://github.com/guo-shaoge) - 非 BIGINT 符号なし整数が文字列/10 進数と比較したときに誤った結果を生成する可能性がある問題を修正 [#41736](https://github.com/pingcap/tidb/issues/41736) @[LittleFall](https://github.com/LittleFall) - メモリ制限超過により以前の`ANALYZE`ステートメントが強制終了されると、同じセッション内の現在の`ANALYZE`ステートメントも強制終了される可能性がある問題を修正しました [#41825](https://github.com/pingcap/tidb/issues/41825) @[XuHuaiyu](https://github.com/XuHuaiyu) diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 7c0d18964d995..ffe78a368c3b5 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -53,15 +53,15 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 詳細については[ドキュメント](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)参照してください。 -- 非準備済みステートメントの実行プランをキャッシュする機能の強化（実験的） [＃36598](https://github.com/pingcap/tidb/issues/36598) @ [qw4990](https://github.com/qw4990) +- 非プリペアドステートメントの実行プランをキャッシュする機能の強化（実験的） [＃36598](https://github.com/pingcap/tidb/issues/36598) @ [qw4990](https://github.com/qw4990) - TiDB v7.0.0では、同時実行OLTPの負荷容量を向上させるための実験的機能として、非準備プランキャッシュが導入されました。v7.1.0では、この機能が強化され、より多くのSQL文のキャッシュがサポートされるようになりました。 + TiDB v7.0.0では、同時実行OLTPの処理能力を向上させるための実験的機能として、非プリペアドプランキャッシュが導入されました。v7.1.0では、この機能が強化され、より多くのSQL文のキャッシュがサポートされるようになりました。 - メモリ使用率を向上させるため、TiDB v7.1.0 では、非プリペアドプランキャッシュと準備済みのプランキャッシュのキャッシュプールを統合します。キャッシュサイズはシステム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を使用して制御できます。システム変数[`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610)と[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)は非推奨です。 + メモリ使用率を向上させるため、TiDB v7.1.0 では、非プリペアドプランキャッシュとプリペアドプランキャッシュのキャッシュプールを統合します。キャッシュサイズはシステム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を使用して制御できます。システム変数[`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610)と[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)は非推奨です。 - 前方互換性を維持するため、以前のバージョンからv7.1.0以降のバージョンにアップグレードする場合、キャッシュサイズ`tidb_session_plan_cache_size` `tidb_prepared_plan_cache_size`と同じ値のままになり、 [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)アップグレード前の設定のままになります。十分なパフォーマンステストを行った後、 `tidb_enable_non_prepared_plan_cache`を使用して非準備プランキャッシュを有効化できます。新規に作成されたクラスターでは、非準備プランキャッシュはデフォルトで有効化されています。 + 前方互換性を維持するため、以前のバージョンからv7.1.0以降のバージョンにアップグレードする場合、キャッシュサイズ`tidb_session_plan_cache_size`は`tidb_prepared_plan_cache_size`と同じ値のままになり、 [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)アップグレード前の設定のままになります。十分なパフォーマンステストを行った後、 `tidb_enable_non_prepared_plan_cache`を使用して非プリペアドプランキャッシュを有効化できます。新規に作成されたクラスターでは、非プリペアドプランキャッシュはデフォルトで有効化されています。 - 非準備プランキャッシュは、デフォルトではDML文をサポートしません。この制限を解除するには、システム変数[`tidb_enable_non_prepared_plan_cache_for_dml`](/system-variables.md#tidb_enable_non_prepared_plan_cache_for_dml-new-in-v710)を`ON`に設定してください。 + 非プリペアドプランキャッシュは、デフォルトではDML文をサポートしません。この制限を解除するには、システム変数[`tidb_enable_non_prepared_plan_cache_for_dml`](/system-variables.md#tidb_enable_non_prepared_plan_cache_for_dml-new-in-v710)を`ON`に設定してください。 詳細については[ドキュメント](/sql-non-prepared-plan-cache.md)参照してください。 @@ -274,9 +274,9 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`tidb_enable_row_level_checksum`](/system-variables.md#tidb_enable_row_level_checksum-new-in-v710) | 新しく追加された | 単一行データ機能に対して TiCDC データ整合性検証を有効にするかどうかを制御します。 | | [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) | 新しく追加された | この変数は、オプティマイザをより細かく制御し、オプティマイザの動作の変更によって引き起こされるアップグレード後のパフォーマンスの低下を防ぐのに役立ちます。 | | [`tidb_plan_cache_invalidation_on_fresh_stats`](/system-variables.md#tidb_plan_cache_invalidation_on_fresh_stats-new-in-v710) | 新しく追加された | 関連テーブルの統計が更新されたときにプラン キャッシュを自動的に無効にするかどうかを制御します。 | -| [`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-new-in-v710) | 新しく追加された | 準備済みプラン キャッシュまたは非プリペアドプラン キャッシュにキャッシュできるプランの最大サイズを制御します。 | +| [`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-new-in-v710) | 新しく追加された | プリペアドプランキャッシュまたは非プリペアドプランキャッシュにキャッシュできるプランの最大サイズを制御します。 | | [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) | 新しく追加された | ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 | -| [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710) | 新しく追加された | キャッシュできるプランの最大数を制御します。準備済みプランのキャッシュと非プリペアドプランのキャッシュは同じキャッシュを共有します。 | +| [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710) | 新しく追加された | キャッシュできるプランの最大数を制御します。プリペアドプランキャッシュと非プリペアドプランキャッシュは同じキャッシュを共有します。 | ### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} @@ -397,7 +397,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - `ADMIN SHOW DDL JOBS LIMIT`誤った結果を返す問題を修正[＃42298](https://github.com/pingcap/tidb/issues/42298) @ [CbcWestwolf](https://github.com/CbcWestwolf) - `UNION` [＃42563](https://github.com/pingcap/tidb/issues/42563) @ [lcwangchao](https://github.com/lcwangchao)でユニオンビューと一時テーブルをクエリするときに発生する TiDBpanic問題を修正しました。 - トランザクション[＃39664](https://github.com/pingcap/tidb/issues/39664) @ [tiancaiamao](https://github.com/tiancaiamao)で複数のステートメントをコミットするときにテーブル名の変更が有効にならない問題を修正しました - - 時間変換[＃42439](https://github.com/pingcap/tidb/issues/42439) @ [qw4990](https://github.com/qw4990)中に準備済みプラン キャッシュと非プリペアドプラン キャッシュの動作間の非互換性の問題を修正しました + - 時刻変換中にプリペアドプランキャッシュと非プリペアドプランキャッシュの動作間の非互換性の問題を修正しました[＃42439](https://github.com/pingcap/tidb/issues/42439) @ [qw4990](https://github.com/qw4990) - Decimal 型[＃43311](https://github.com/pingcap/tidb/issues/43311) @ [qw4990](https://github.com/qw4990)のプラン キャッシュによって発生する誤った結果を修正しました - 間違ったフィールドタイプチェック[＃42459](https://github.com/pingcap/tidb/issues/42459) @ [AilinKid](https://github.com/AilinKid)による、null 認識アンチ結合 (NAAJ) での TiDBpanic問題を修正しました。 - RC分離レベルでの悲観的トランザクションにおけるDML実行の失敗により、データとインデックス[＃43294](https://github.com/pingcap/tidb/issues/43294) @ [ekexium](https://github.com/ekexium)の間に不整合が発生する可能性がある問題を修正しました。 diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 0804b73047b9e..997da81b85f98 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -150,7 +150,7 @@ TiDB バージョン: 7.2.0 | 変数名 | 変更の種類 | 説明 | | -------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`last_insert_id`](/system-variables.md#last_insert_id) | 変更 | MySQL の最大値と一致させるため、最大値を`9223372036854775807`から`18446744073709551615`に変更します。 | -| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | 追加テストの後、デフォルト値を`OFF`から`ON`に変更します。これは、準備されていない実行プラン キャッシュが有効になることを意味します。 | +| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | 追加テストの後、デフォルト値を`OFF`から`ON`に変更します。これは、非プリペアドプランキャッシュが有効になることを意味します。 | | [`tidb_remove_orderby_in_subquery`](/system-variables.md#tidb_remove_orderby_in_subquery-new-in-v610) | 変更 | さらなるテストの後、デフォルト値を`OFF`から`ON`に変更します。これは、オプティマイザがサブクエリ内の`ORDER BY`句を削除することを意味します。 | | [`tidb_analyze_skip_column_types`](/system-variables.md#tidb_analyze_skip_column_types-new-in-v720) | 新しく追加された | `ANALYZE`コマンドを実行して統計情報を収集する際に、どのタイプの列を統計収集から除外するかを制御します。この変数は、 [`tidb_analyze_version = 2`](/system-variables.md#tidb_analyze_version-new-in-v510)の場合にのみ適用されます。 `ANALYZE TABLE t COLUMNS c1, ..., cn`の構文を使用する場合、指定された列のタイプが`tidb_analyze_skip_column_types`に含まれている場合、この列の統計情報は収集されません。 | | [`tidb_enable_check_constraint`](/system-variables.md#tidb_enable_check_constraint-new-in-v720) | 新しく追加された | `CHECK`制約を有効にするかどうかを制御します。デフォルト値は`OFF`で、これはこの機能が無効になっていることを意味します。 | diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 5b5c7a43060a9..5c0d0557c9ced 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -63,11 +63,11 @@ TiDB バージョン: 7.4.0 詳細については[ドキュメント](/tidb-global-sort.md)参照してください。 -- 非準備済みステートメントの実行プランのキャッシュをサポート (GA) [＃36598](https://github.com/pingcap/tidb/issues/36598) @ [qw4990](https://github.com/qw4990) +- 非プリペアドステートメントの実行プランのキャッシュをサポート (GA) [＃36598](https://github.com/pingcap/tidb/issues/36598) @ [qw4990](https://github.com/qw4990) - TiDB v7.0.0では、同時実行OLTPの負荷容量を向上させるための実験的機能として、非準備プランキャッシュが導入されました。v7.4.0ではこの機能がGAとなります。実行プランキャッシュはより多くのシナリオに適用され、TiDBの同時実行処理能力が向上します。 + TiDB v7.0.0では、同時実行OLTPの処理能力を向上させるための実験的機能として、非プリペアドプランキャッシュが導入されました。v7.4.0ではこの機能がGAとなります。実行プランキャッシュはより多くのシナリオに適用され、TiDBの同時実行処理能力が向上します。 - 非準備プランキャッシュを有効にすると、メモリとCPUのオーバーヘッドが増加する可能性があり、すべての状況に適しているとは限りません。v7.4.0以降、この機能はデフォルトで無効になっています。1 [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)有効にし、 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)でキャッシュサイズを制御できます。 + 非プリペアドプランキャッシュを有効にすると、メモリとCPUのオーバーヘッドが増加する可能性があり、すべての状況に適しているとは限りません。v7.4.0以降、この機能はデフォルトで無効になっています。[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)を有効にし、 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)でキャッシュサイズを制御できます。 また、この機能はデフォルトではDML文をサポートしておらず、SQL文には一定の制限があります。詳細については、 [制限](/sql-non-prepared-plan-cache.md#restrictions)参照してください。 @@ -254,7 +254,7 @@ TiDB バージョン: 7.4.0 | 変数名 | タイプを変更 | 説明 | | ------------------------------------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tidb_enable_tiflash_pipeline_model` | 削除済み | この変数は、 TiFlashパイプライン実行モデルを有効にするかどうかを制御するために使用されます。v7.4.0以降では、 TiFlashリソース制御機能を有効にすると、 TiFlashパイプライン実行モデルも自動的に有効になります。 | -| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | さらにテストを行った後、デフォルト値を`ON`から`OFF`に変更します。これは、準備されていない実行プラン キャッシュが無効であることを意味します。 | +| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | さらにテストを行った後、デフォルト値を`ON`から`OFF`に変更します。これは、非プリペアドプランキャッシュが無効であることを意味します。 | | [`default_collation_for_utf8mb4`](/system-variables.md#default_collation_for_utf8mb4-new-in-v740) | 新しく追加された | `utf8mb4`文字セットのデフォルトの照合順序を制御します。デフォルト値は`utf8mb4_bin`です。 | | [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) | 新しく追加された | 有効にするクラウドストレージURI を指定します[グローバルソート](/tidb-global-sort.md) 。 | | [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740) | 新しく追加された | オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御します。デフォルトの値は`ON`です。3 に`OFF`すると、他に利用可能な実行プランがない限り、オプティマイザはテーブルのハッシュ結合を選択しません。 | diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 9a3d6232124bc..f1b1406c08f51 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -49,7 +49,7 @@ TiDB バージョン: 8.4.0 - 冗長性を排除し、同じメモリ消費量でより多くの実行プランをキャッシュします。 - インスタンスに固定サイズのメモリを割り当て、メモリ使用量をより効果的に制限します。 - v8.4.0 では、インスタンス レベルの実行プラン キャッシュはクエリ実行プランのキャッシュのみをサポートしており、デフォルトでは無効になっています。 [`tidb_enable_instance_plan_cache`](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)を使用してこの機能を有効にし、 [`tidb_instance_plan_cache_max_size`](/system-variables.md#tidb_instance_plan_cache_max_size-new-in-v840)を使用して最大メモリ使用量を設定できます。この機能を有効にする前に、[準備された実行プランキャッシュ](/sql-prepared-plan-cache.md)と[準備されていない実行プランのキャッシュ](/sql-non-prepared-plan-cache.md)を無効にしてください。 + v8.4.0 では、インスタンス レベルの実行プラン キャッシュはクエリ実行プランのキャッシュのみをサポートしており、デフォルトでは無効になっています。 [`tidb_enable_instance_plan_cache`](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)を使用してこの機能を有効にし、 [`tidb_instance_plan_cache_max_size`](/system-variables.md#tidb_instance_plan_cache_max_size-new-in-v840)を使用して最大メモリ使用量を設定できます。この機能を有効にする前に、[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)と[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を無効にしてください。 詳細については、 [ドキュメント](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)を参照してください。 diff --git a/sql-non-prepared-plan-cache.md b/sql-non-prepared-plan-cache.md index 8f05295e81252..a9f01d20efeef 100644 --- a/sql-non-prepared-plan-cache.md +++ b/sql-non-prepared-plan-cache.md @@ -1,19 +1,19 @@ --- title: SQL Non-Prepared Execution Plan Cache -summary: TiDB の SQL 非準備実行プラン キャッシュの原理、使用法、および例について学習します。 +summary: TiDB の SQL 非プリペアドプランキャッシュの原理、使用法、および例について学習します。 --- # SQL Non-Prepared Execution Plan Cache {#sql-non-prepared-execution-plan-cache} TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache.md)と同様に、一部の`PREPARE`以外のステートメントに対して実行プランのキャッシュをサポートしています。この機能により、これらのステートメントは最適化フェーズをスキップし、パフォーマンスを向上させることができます。 -非準備プランキャッシュを有効にすると、メモリとCPUのオーバーヘッドが増加する可能性があり、すべての状況に適しているとは限りません。この機能をシナリオで有効にするかどうかを判断するには、セクション[パフォーマンス上の利点](#performance-benefits)と[メモリ監視](#monitoring)を参照してください。 +非プリペアドプランキャッシュを有効にすると、メモリとCPUのオーバーヘッドが増加する可能性があり、すべての状況に適しているとは限りません。この機能をシナリオで有効にするかどうかを判断するには、セクション[パフォーマンス上の利点](#performance-benefits)と[メモリ監視](#monitoring)を参照してください。 ## 原理 {#principle} -非準備プランキャッシュは、 [準備されたプランキャッシュ](/sql-prepared-plan-cache.md)とキャッシュを共有するセッションレベルの機能です。非準備プランキャッシュの基本原理は次のとおりです。 +非プリペアドプランキャッシュは、 [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)とキャッシュを共有するセッションレベルの機能です。非プリペアドプランキャッシュの基本原理は次のとおりです。 -1. 非準備プランキャッシュを有効にすると、TiDBはまず抽象構文木（AST）に基づいてクエリをパラメータ化します。例えば、 `SELECT * FROM t WHERE b < 10 AND a = 1` `SELECT * FROM t WHERE b < ? and a = ?`としてパラメータ化されます。 +1. 非プリペアドプランキャッシュを有効にすると、TiDBはまず抽象構文木（AST）に基づいてクエリをパラメータ化します。例えば、 `SELECT * FROM t WHERE b < 10 AND a = 1` `SELECT * FROM t WHERE b < ? and a = ?`としてパラメータ化されます。 2. 次に、TiDB はパラメータ化されたクエリを使用してプラン キャッシュを検索します。 3. 再利用可能なプランが見つかった場合は、それが直接使用され、最適化フェーズはスキップされます。 4. それ以外の場合、オプティマイザーは新しいプランを生成し、それをキャッシュに戻して、後続のクエリで再利用します。 @@ -26,7 +26,7 @@ TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache > **注記：** > -> `tidb_session_plan_cache_size`で指定されたメモリは、準備済みプランキャッシュと非プリペアドプランキャッシュで共有されます。現在のクラスターで準備済みプランキャッシュを有効にしている場合、非プリペアドプランキャッシュを有効にすると、元の準備済みプランキャッシュのヒット率が低下する可能性があります。 +> `tidb_session_plan_cache_size`で指定されたメモリは、プリペアドプランキャッシュと非プリペアドプランキャッシュで共有されます。現在のクラスターでプリペアドプランキャッシュを有効にしている場合、非プリペアドプランキャッシュを有効にすると、元のプリペアドプランキャッシュのヒット率が低下する可能性があります。 ## 例 {#example} @@ -78,9 +78,9 @@ TiDBは、パラメータ化されたクエリに対して1つのプランのみ ### 使用制限 {#usage-restrictions} -上記のリスクと、実行プランキャッシュが大きなメリットをもたらすのは単純なクエリのみであるという事実（クエリが複雑で実行に時間がかかる場合、実行プランキャッシュの使用はあまり役に立たない可能性があります）を考慮し、TiDBでは非準備プランキャッシュのスコープに厳しい制限を設けています。制限は次のとおりです。 +上記のリスクと、実行プランキャッシュが大きなメリットをもたらすのは単純なクエリのみであるという事実（クエリが複雑で実行に時間がかかる場合、実行プランキャッシュの使用はあまり役に立たない可能性があります）を考慮し、TiDBでは非プリペアドプランキャッシュのスコープに厳しい制限を設けています。制限は次のとおりです。 -- [準備されたプランキャッシュ](/sql-prepared-plan-cache.md)でサポートされていないクエリまたはプランは、非プリペアドプラン キャッシュでもサポートされません。 +- [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)でサポートされていないクエリまたはプランは、非プリペアドプラン キャッシュでもサポートされません。 - `Window`や`Having`などの複雑な演算子を含むクエリはサポートされていません。 - 3 つ以上の`Join`テーブルまたはサブクエリを含むクエリはサポートされていません。 - `ORDER BY 1`や`GROUP BY a+1`など、 `ORDER BY`または`GROUP BY`直後に数字や式が含まれるクエリはサポートされていません`ORDER BY column_name`と`GROUP BY column_name`のみがサポートされています。 @@ -95,7 +95,7 @@ After you enable this feature, the optimizer quickly evaluates the query. If it ## パフォーマンス上の利点 {#performance-benefits} -社内テストでは、非準備プランキャッシュ機能を有効にすると、ほとんどのTPシナリオで大幅なパフォーマンス向上が見られました。例えば、TPC-Cテストでは約4%、一部の銀行業務ワークロードでは10%以上、Sysbench RangeScanでは15%のパフォーマンス向上が見られました。 +社内テストでは、非プリペアドプランキャッシュ機能を有効にすると、ほとんどのTPシナリオで大幅なパフォーマンス向上が見られました。例えば、TPC-Cテストでは約4%、一部の銀行業務ワークロードでは10%以上、Sysbench RangeScanでは15%のパフォーマンス向上が見られました。 ただし、この機能は、クエリがサポートされているかどうかの判断、クエリのパラメータ化、キャッシュ内のプランの検索など、メモリとCPUのオーバーヘッドを増加させます。ワークロード内のクエリの大部分をキャッシュで処理できない場合、この機能を有効にするとパフォーマンスに悪影響を与える可能性があります。 @@ -105,7 +105,7 @@ After you enable this feature, the optimizer quickly evaluates the query. If it ## 診断 {#diagnostics} -非準備プランキャッシュを有効にした後、 `EXPLAIN FORMAT='plan_cache' SELECT ...`ステートメントを実行して、クエリがキャッシュにヒットするかどうかを確認できます。キャッシュにヒットできないクエリの場合、システムは警告でその理由を返します。 +非プリペアドプランキャッシュを有効にした後、 `EXPLAIN FORMAT='plan_cache' SELECT ...`ステートメントを実行して、クエリがキャッシュにヒットするかどうかを確認できます。キャッシュにヒットできないクエリの場合、システムは警告でその理由を返します。 `FORMAT='plan_cache'`追加しないと、 `EXPLAIN`ステートメントはキャッシュにヒットしないことに注意してください。 diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 486a09011d31c..ca01408c77a8b 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -1,9 +1,9 @@ --- title: SQL Prepared Execution Plan Cache -summary: TiDB の SQL 準備実行プラン キャッシュについて学習します。 +summary: TiDB の SQL プリペアドプランキャッシュについて学習します。 --- -# SQL 準備済み実行プランキャッシュ {#sql-prepared-execution-plan-cache} +# SQL プリペアドプランキャッシュ {#sql-prepared-execution-plan-cache} TiDBは、 `Prepare`と`Execute`クエリの実行プランのキャッシュをサポートしています。これには、以下の2つの形式のプリペアドステートメントが含まれます。 @@ -14,7 +14,7 @@ TiDB オプティマイザーは、これら 2 種類のクエリを同じ方法 実行プランキャッシュが有効な場合、最初の実行では、各`Prepare`ごとに現在のクエリが実行プランキャッシュを使用できるかどうかが確認され、使用できる場合は、生成された実行プランがLRU（Least Recently Used）リンクリストで実装されたキャッシュに格納されます。後続の`Execute`クエリでは、キャッシュから実行プランが取得され、その可用性が確認されます。確認が成功した場合、実行プラン生成のステップはスキップされます。そうでない場合は、実行プランが再生成され、キャッシュに保存されます。 -TiDBは、 `Prepare` / `Execute`文と同様に、 `PREPARE`以外の文についても実行計画のキャッシュをサポートしています。詳細については、 [準備されていないプランキャッシュ](/sql-non-prepared-plan-cache.md)を参照してください。 +TiDBは、 `Prepare` / `Execute`文と同様に、 `PREPARE`以外の文についても実行計画のキャッシュをサポートしています。詳細については、 [非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を参照してください。 TiDB の現在のバージョンでは、 `Prepare`ステートメントが次のいずれかの条件を満たす場合、クエリまたはプランはキャッシュされません。 @@ -58,11 +58,11 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで - `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2 つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行プランを生成しません。 - キャッシュの無効化と削除を考慮しない場合、実行プラン キャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行プランが生成されます。たとえば、フィルター条件が`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)介して制御できます。 +バージョン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)参照してください。 +> [`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`ステートメントがキャッシュされた実行プランを使用したかどうかを確認できます。次に例を示します。 @@ -346,7 +346,7 @@ mysql> select @@last_plan_from_cache; -- Reuse the last plan -TiDBページの**Executor**セクションの[Grafanaダッシュボード](/grafana-tidb-dashboard.md)には、「プランキャッシュOPSを使用するクエリ」と「プランキャッシュミスOPS」のグラフがあります。これらのグラフは、TiDBとアプリケーションの両方がSQLプランキャッシュが正しく動作するように正しく設定されているかどうかを確認できます。同じページの**Server**セクションには、「準備済みステートメント数」のグラフがあります。アプリケーションが準備済みステートメントを使用している場合、このグラフは0以外の値を示します。これはSQLプランキャッシュが正しく機能するために必要なものです。 +TiDBページの**Executor**セクションの[Grafanaダッシュボード](/grafana-tidb-dashboard.md)には、「プランキャッシュOPSを使用するクエリ」と「プランキャッシュミスOPS」のグラフがあります。これらのグラフは、TiDBとアプリケーションの両方がSQLプランキャッシュが正しく動作するように正しく設定されているかどうかを確認できます。同じページの**Server**セクションには、「プリペアドステートメント数」のグラフがあります。アプリケーションがプリペアドステートメントを使用している場合、このグラフは0以外の値を示します。これはSQLプランキャッシュが正しく機能するために必要なものです。 ![sql\_plan\_cache](/media/performance/sql_plan_cache.png) diff --git a/system-variables.md b/system-variables.md index d1b21e66c1d82..d5487987783a8 100644 --- a/system-variables.md +++ b/system-variables.md @@ -2539,7 +2539,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、インスタンス プラン キャッシュ機能を有効にするかどうかを制御します。この機能はインスタンス レベルの実行プラン キャッシュを実装しており、同じ TiDB インスタンス内のすべてのセッションが実行プラン キャッシュを共有できるため、メモリ使用率が向上します。インスタンス プラン キャッシュを有効にする前に、セッション レベル[準備された実行プランキャッシュ](/sql-prepared-plan-cache.md)キャッシュ[準備されていない実行プランのキャッシュ](/sql-non-prepared-plan-cache.md)を無効にすることをお勧めします。 +- この変数は、インスタンス プラン キャッシュ機能を有効にするかどうかを制御します。この機能はインスタンス レベルの実行プラン キャッシュを実装しており、同じ TiDB インスタンス内のすべてのセッションが実行プラン キャッシュを共有できるため、メモリ使用率が向上します。インスタンス プラン キャッシュを有効にする前に、セッション レベル[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)と[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を無効にすることをお勧めします。 ### tidb_enable_ordered_result_mode {#tidb-enable-ordered-result-mode} @@ -5462,7 +5462,7 @@ SHOW WARNINGS; - 型: Float - デフォルト値: `0.1` - 範囲: `[0, 1]` -- 準備されたプラン キャッシュがメモリ保護メカニズムをトリガーするしきい値。詳細については、[プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md)ご覧ください。 +- プリペアドプランキャッシュがメモリ保護メカニズムをトリガーするしきい値。詳細については、[プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md)ご覧ください。 - この設定は以前は`tidb.toml`オプション ( `prepared-plan-cache.memory-guard-ratio` ) でしたが、TiDB v6.1.0 以降はシステム変数に変更されました。 ### tidb_prepared_plan_cache_size v6.1.0で追加 {#tidb-prepared-plan-cache-size-span-class-version-mark-new-in-v6-1-0-span} diff --git a/tidb-cloud/tidb-cloud-sql-tuning-overview.md b/tidb-cloud/tidb-cloud-sql-tuning-overview.md index a0de3aa003b44..18963682c660d 100644 --- a/tidb-cloud/tidb-cloud-sql-tuning-overview.md +++ b/tidb-cloud/tidb-cloud-sql-tuning-overview.md @@ -57,7 +57,7 @@ TiDBによって選択された実行プランが最適でない場合は、 EXP これらの等価性の変更により、クエリは論理実行プランで扱いやすくなります。等価性の変更後、TiDB は元のクエリと等価なクエリ プラン構造を取得し、データ分布と演算子の特定の実行オーバーヘッドに基づいて最終的な実行プランを取得します。詳細については、 [SQLの物理的最適化](/sql-physical-optimization.md)参照してください。 -また、実行プラン キャッシュを準備するで紹介したように、TiDB は、 `PREPARE`ステートメントの実行時に実行プランの作成オーバーヘッドを削減するために、[実行プランキャッシュを準備する](/sql-prepared-plan-cache.md)。 +また、プリペアドプランキャッシュで紹介したように、TiDB は、 `PREPARE`ステートメントの実行時に実行プランの作成オーバーヘッドを削減するために、[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を提供しています。 ### フルテーブルスキャンを最適化 {#optimize-full-table-scan} diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md index 88dac8c507d76..951813bbbc778 100644 --- a/tidb-cloud/tidb-cloud-tune-performance-overview.md +++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md @@ -59,11 +59,11 @@ TiDB Cloudコンソールには、ユーザー応答時間のトラブルシュ 1. [概要タブ](/tidb-cloud/monitor-tidb-cluster.md)の左側にある TiDB のバージョンを確認してください。v6.0.0 以前のバージョンの場合は、 [PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)に問い合わせて、Prepared plan cache、Raft エンジン、TiKV AsyncIO 機能を有効にできるかどうかを確認することをお勧めします。これらの機能を有効にし、アプリケーション側のチューニングを行うことで、スループット性能を大幅に向上させ、レイテンシーとリソース使用率を削減できます。 2. 必要に応じて、TiDB トークンの制限を増やしてスループットを向上させることができます。 -3. 準備済みプラン キャッシュ機能が有効になっていて、ユーザー側で JDBC を使用する場合は、次の構成を使用することをお勧めします。 +3. プリペアドプランキャッシュ機能が有効になっていて、ユーザー側で JDBC を使用する場合は、次の構成を使用することをお勧めします。 useServerPrepStmts=true&cachePrepStmts=true& prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480&useConfigs=maxPerformance - JDBC を使用せず、現在の TiDB クラスターの準備済みプランキャッシュ機能を最大限に活用したい場合は、クライアント側でプリペアドステートメントオブジェクトをキャッシュする必要があります。StmtPrepare および StmtClose の呼び出しをリセットする必要はありません。クエリごとに呼び出されるコマンドの数を 3 から 1 に減らします。パフォーマンス要件とクライアント側の変更の量によっては、ある程度の開発作業が必要になります。1 [PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)参照してください。 + JDBC を使用せず、現在の TiDB クラスターのプリペアドプランキャッシュ機能を最大限に活用したい場合は、クライアント側でプリペアドステートメントオブジェクトをキャッシュする必要があります。StmtPrepare および StmtClose の呼び出しをリセットする必要はありません。クエリごとに呼び出されるコマンドの数を 3 から 1 に減らします。パフォーマンス要件とクライアント側の変更の量によっては、ある程度の開発作業が必要になります。[PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)に問い合わせてください。 ### TiDBクラスタのボトルネック {#bottlenecks-in-the-tidb-cluster} @@ -114,7 +114,7 @@ SQL パフォーマンス チューニングの詳細については、 [SQLチ | アクション | 効果 | | :--------------------------------- | :--------------------------------------------------------------------------------------- | -| 準備されたプランキャッシュ + JDBC | スループット パフォーマンスが大幅に向上し、レイテンシーが大幅に削減され、TiDB の平均 CPU 使用率が大幅に削減されます。 | +| プリペアドプランキャッシュ + JDBC | スループット パフォーマンスが大幅に向上し、レイテンシーが大幅に削減され、TiDB の平均 CPU 使用率が大幅に削減されます。 | | TiKVでAsyncIOとRaftエンジンを有効にする | スループット性能が若干向上します。有効にするには、 [PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 | | クラスター化インデックス | スループットパフォーマンスが大幅に向上します。 | | TiDBノードのスケールアウト | スループットパフォーマンスが大幅に向上します。 | diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 3030eada7973b..47a251e31e79b 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -26,7 +26,7 @@ TiDBのパフォーマンスを最適化するには、さまざまな設定を TiDBのパフォーマンスを最適化するために、一般的に以下の設定が使用されます。 -- [SQL準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[準備されていないプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) +- [SQLプリペアドプランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) - [オプティマイザー修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 - ストレージエンジン[Titan](/storage-engine/titan-overview.md)をより積極的に活用する。 - 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。 @@ -59,7 +59,7 @@ SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855: | システム変数 | 説明 | 注記 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | [`tidb_enable_instance_plan_cache`](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)と[`tidb_instance_plan_cache_max_size`](/system-variables.md#tidb_instance_plan_cache_max_size-new-in-v840) | セッションレベルのキャッシュではなく、インスタンスレベルのプランキャッシュを使用してください。これにより、接続数が多いワークロードや、プリペアドステートメントの使用頻度が高いワークロードのパフォーマンスが大幅に向上します。 | これは実験的機能です。まずは非本番環境でテストし、プランキャッシュサイズが増加するにつれてメモリ使用量を監視してください。 | -| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | プリペアドステートメントを使用しないアプリケーションのコンパイルコストを削減するには、 [準備されていないプランキャッシュ](/sql-non-prepared-plan-cache.md)機能を有効にしてください。 | 該当なし | +| [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | プリペアドステートメントを使用しないアプリケーションのコンパイルコストを削減するには、 [非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)機能を有効にしてください。 | 該当なし | | [`tidb_ignore_prepared_cache_close_stmt`](/system-variables.md#tidb_ignore_prepared_cache_close_stmt-new-in-v600) | プリペアドステートメントを使用するアプリケーション向けに、実行後にプランを閉じるキャッシュプランを作成します。 | 該当なし | | [`tidb_analyze_column_options`](/system-variables.md#tidb_analyze_column_options-new-in-v830) | 列統計情報の欠落による最適とは言えない実行計画を回避するため、すべての列の統計情報を収集してください。 | 該当なし | | [`tidb_stats_load_sync_wait`](/system-variables.md#tidb_stats_load_sync_wait-new-in-v540) | 統計情報の同期読み込みのタイムアウト時間を、デフォルトの100ミリ秒から2秒に延長します。これにより、TiDBはクエリコンパイル前に必要な統計情報を確実に読み込むことができます。 | この値を大きくすると、クエリコンパイル前の同期待機時間が長くなります。 | diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index d52b90de34ca1..5b2d606d4e1b2 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -120,7 +120,7 @@ TiDBノードは起動後、統計情報をメモリに読み込む必要があ 詳細については[統計入門](/statistics.md)参照してください。 -#### 準備されたステートメントは使いすぎです {#prepared-statements-are-overused} +#### プリペアドステートメントの過剰使用 {#prepared-statements-are-overused} クライアント側はプリペアドステートメントを作成し続けますが、実行しません[`deallocate prepare stmt`](/sql-prepared-plan-cache.md#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement) 。これによりメモリ消費量が増加し続け、最終的にはTiDB OOMが発生します。これは、プリペアドステートメントによって占有されたメモリがセッションが終了するまで解放されないためです。これは、長時間接続セッションにおいて特に重要です。