prepared plan cache: Enable by default (pingcap#4036)

* prepared plan cache: Enable by default

* Update sql-prepare-plan-cache.md

* Update sql-prepare-plan-cache.md

Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com>

Author: Null not nil

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
 
-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.
+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).

optimizer-hints.md

@@ -304,7 +304,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 when [prepare-plan-cache](/tidb-configuration-file.md#prepared-plan-cache) is enabled.
+This hint is used to temporarily disable the Plan Cache for a certain type of queries.
 
 In the following example, the Plan Cache is forcibly disabled when executing the `prepare` statement.
 

sql-prepare-plan-cache.md

@@ -5,16 +5,12 @@ summary: Learn about SQL Prepare Execution Plan Cache in TiDB.
 
 # SQL Prepare Execution Plan Cache
 
-TiDB supports execution plan caching for `Prepare` / `Execute` queries.
+In the current development release of TiDB, the execution plan of prepared statements is cached by default. This includes both forms of prepared statements:
 
-There are two forms of `Prepare` / `Execute` queries:
+- Using the `COM_STMT_PREPARE` and `COM_STMT_EXECUTE` protocol features.
+- Using the SQL statements `PREPARE` and `EXECUTE`.
 
-- In the binary communication protocol, use `COM_STMT_PREPARE` and
-  `COM_STMT_EXECUTE` to execute general parameterized SQL queries;
-- In the text communication protocol, use `COM_QUERY` to execute `Prepare` and
-  `Execution` SQL queries.
-
-The optimizer handles these two types of queries in the same way: when preparing, the parameterized query is parsed into an AST (Abstract Syntax Tree) and cached; in later execution, the execution plan is generated based on the stored AST and specific parameter values.
+The TiDB optimizer handles these two types of queries in the same way: when preparing, the parameterized query is parsed into an AST (Abstract Syntax Tree) and cached; in later execution, the execution plan is generated based on the stored AST and specific parameter values.
 
 When the execution plan cache is enabled, in the first execution every `Prepare` statement checks whether the current query can use the execution plan cache, and if the query can use it, then put the generated execution plan into a cache implemented by LRU (Least Recently Used) linked list. In the subsequent `Execute` queries, the execution plan is obtained from the cache and checked for availability. If the check succeeds, the step of generating an execution plan is skipped. Otherwise, the execution plan is regenerated and saved in the cache.
 
@@ -54,7 +50,7 @@ performance:
 - 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.
 
-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 configuration file.
+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.
 
 > **Note：**
 >

tidb-configuration-file.md

@@ -289,7 +289,7 @@ Configuration items related to performance.
 
 - The maximum memory limit for the Prepared Least Recently Used (LRU) caching. If this value exceeds `performance.max-memory * (1 - prepared-plan-cache.memory-guard-ratio)`, the elements in the LRU are removed.
 - Default value: `0`
-- This configuration only takes effect when `prepared-plan-cache.enabled` is `true`. When the size of the LRU is greater than `prepared-plan-cache.capacity`, the elements in the LRU are also removed.
+- This configuration takes effect when `prepared-plan-cache.enabled` is `true` (default). When the size of the LRU is greater than `prepared-plan-cache.capacity`, the elements in the LRU are also removed.
 
 ### `stmt-count-limit`
 
@@ -372,14 +372,10 @@ 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`
+- Default value: `true`
 
 ### `capacity`