From 943f5128fdfc60b5312fc330c43cdebb8525e048 Mon Sep 17 00:00:00 2001 From: ti-srebot <66930949+ti-srebot@users.noreply.github.com> Date: Wed, 24 Mar 2021 16:43:37 +0800 Subject: [PATCH] Revert "prepared plan cache: Enable by default (#4036)" (#5007) (#5078) --- dashboard/dashboard-faq.md | 2 +- optimizer-hints.md | 2 +- sql-prepare-plan-cache.md | 4 ++-- tidb-configuration-file.md | 9 +++++++++ 4 files changed, 13 insertions(+), 4 deletions(-) diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 0571c22c803d1..51985551d03e3 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -56,4 +56,4 @@ If your deployment tool is TiUP, take the following steps to solve this problem. ### An `invalid connection` error is shown in **Top SQL Statements** and **Recent Slow Queries** on the Overview page -This error is possibly related to the `prepared-plan-cache` feature of TiDB. You can disable `prepared-plan-cache` by updating [TiDB Configuration file](/tidb-configuration-file.md#prepared-plan-cache). +The possible reason is that you have enabled the `prepared-plan-cache` feature of TiDB. As an experimental feature, when enabled, `prepared-plan-cache` might not function properly in specific TiDB versions, which could cause this problem in TiDB Dashboard (and other applications). You can disable `prepared-plan-cache` by updating [TiDB Configuration file](/tidb-configuration-file.md#prepared-plan-cache) to solve this problem. diff --git a/optimizer-hints.md b/optimizer-hints.md index 6894c2416a745..598433dfc44d5 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -313,7 +313,7 @@ In addition to this hint, setting the `tidb_replica_read` environment variable t The `IGNORE_PLAN_CACHE()` hint reminds the optimizer not to use the Plan Cache when handling the current `prepare` statement. -This hint is used to temporarily disable the Plan Cache for a certain type of queries. +This hint is used to temporarily disable the Plan Cache for a certain type of queries when [prepare-plan-cache](/tidb-configuration-file.md#prepared-plan-cache) is enabled. In the following example, the Plan Cache is forcibly disabled when executing the `prepare` statement. diff --git a/sql-prepare-plan-cache.md b/sql-prepare-plan-cache.md index 5d28aa5f53347..74620243f67b5 100644 --- a/sql-prepare-plan-cache.md +++ b/sql-prepare-plan-cache.md @@ -5,7 +5,7 @@ summary: Learn about SQL Prepare Execution Plan Cache in TiDB. # SQL Prepare Execution Plan Cache -In the current development release of TiDB, the execution plan of prepared statements is cached by default. This includes both forms of prepared statements: +TiDB supports execution plan caching for `Prepare` and `Execute` queries. This includes both forms of prepared statements: - Using the `COM_STMT_PREPARE` and `COM_STMT_EXECUTE` protocol features. - Using the SQL statements `PREPARE` and `EXECUTE`. @@ -44,7 +44,7 @@ There are two points worth noting about execution plan caching and query perform - Considering that the parameters of `Execute` are different, the execution plan cache prohibits some aggressive query optimization methods that are closely related to specific parameter values to ensure adaptability. This causes that the query plan may not be optimal for certain parameter values. For example, the filter condition of the query is `where a > ? And a < ?`, the parameters of the first `Execute` statement are `2` and `1` respectively. Considering that these two parameters maybe be `1` and `2` in the next execution time, the optimizer does not generate the optimal `TableDual` execution plan that is specific to current parameter values; - If cache invalidation and elimination are not considered, an execution plan cache is applied to various parameter values, which in theory also result in non-optimal execution plans for certain values. For example, if the filter condition is `where a < ?` and the parameter value used for the first execution is `1`, then the optimizer generates the optimal `IndexScan` execution plan and puts it into the cache. In the subsequent executions, if the value becomes `10000`, the `TableScan` plan might be the better one. But due to the execution plan cache, the previously generated `IndexScan` is used for execution. Therefore, the execution plan cache is more suitable for application scenarios where the query is simple (the ratio of compilation is high) and the execution plan is relatively fixed. -The default capacity for the plan cache is `100` statements. You can configure this by modifying [`prepare-plan-cache`](/tidb-configuration-file.md#prepared-plan-cache) in the TiDB configuration file. +Currently, the execution plan cache is disabled by default. You can enable this feature by enabling the [`prepare-plan-cache`](/tidb-configuration-file.md#prepared-plan-cache) in the TiDB configuration file. > **Noteļ¼š** > diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index 5448e73d202b2..b719610fded41 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -416,6 +416,15 @@ Configuration items related to performance. The Plan Cache configuration of the `PREPARE` statement. +> **Warning:** +> +> This is still an experimental feature. It is **NOT** recommended that you use it in the production environment. + +### `enabled` + +- Determines whether to enable Plan Cache of the `PREPARE` statement. +- Default value: `false` + ### `capacity` - The number of cached statements.