From edbc49d2b66d8d1e33d2a36687f6d808182bd21b Mon Sep 17 00:00:00 2001 From: Kenan Yao Date: Thu, 11 Mar 2021 11:41:02 +0800 Subject: [PATCH] Revert "prepared plan cache: Enable by default (#4036)" This reverts commit 6000b9584ce20466d64b4da1b7112e21b4284678. --- dashboard/dashboard-faq.md | 2 +- optimizer-hints.md | 2 +- sql-prepare-plan-cache.md | 4 ++-- tidb-configuration-file.md | 6 +++++- 4 files changed, 9 insertions(+), 5 deletions(-) diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 8dac0ef972f23..e0aeb8ff2d53d 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -57,4 +57,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 516aa8cbd5f22..87ae9a162d42c 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -314,7 +314,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 ace2736ef34cc..34a5d4ec3707b 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -417,10 +417,14 @@ 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: `true` +- Default value: `false` ### `capacity`