planner: new Plan Cache User Doc

TOC-tidb-cloud.md

@@ -200,8 +200,7 @@
           - [Distinct Optimization](/agg-distinct-optimization.md)
           - [Cost Model](/cost-model.md)
           - [Runtime Filter](/runtime-filter.md)
-        - [Prepared Execution Plan Cache](/sql-prepared-plan-cache.md)
-        - [Non-Prepared Execution Plan Cache](/sql-non-prepared-plan-cache.md)
+        - [SQL Plan Cache](/sql-plan-cache.md)
       - Control Execution Plans
         - [Overview](/control-execution-plan.md)
         - [Optimizer Hints](/optimizer-hints.md)

TOC.md

@@ -362,8 +362,7 @@
         - [Distinct Optimization](/agg-distinct-optimization.md)
         - [Cost Model](/cost-model.md)
         - [Runtime Filter](/runtime-filter.md)
-      - [Prepared Execution Plan Cache](/sql-prepared-plan-cache.md)
-      - [Non-Prepared Execution Plan Cache](/sql-non-prepared-plan-cache.md)
+      - [SQL Plan Cache](/sql-plan-cache.md)
     - Control Execution Plans
       - [Overview](/control-execution-plan.md)
       - [Optimizer Hints](/optimizer-hints.md)

basic-features.md

@@ -99,9 +99,7 @@ You can try out TiDB features on [TiDB Playground](https://play.tidbcloud.com/?u
 | Advanced SQL features | 8.5 | 8.1 | 7.5 | 7.1 | 6.5 | 6.1 | 5.4 | 5.3 | 5.2 | 5.1 |
 |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
 | [Vector search](/vector-search/vector-search-overview.md) |  E |  N |  N  | N | N | N | N | N | N | N |
-| [Prepared statement cache](/sql-prepared-plan-cache.md) | Y | Y | Y | Y | Y | Y | Y | Y | E | E |
-| [Non-prepared statement cache](/sql-non-prepared-plan-cache.md) | Y | Y | Y | E | N | N | N | N | N | N |
-| [Instance-level execution plan cache](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) | E | N | N | N | N | N | N | N | N | N |
+| [SQL Plan cache](/sql-plan-cache.md) | Y | Y | Y | Y | Y | Y | Y | Y | E | E |
 | [SQL binding](/sql-plan-management.md#sql-binding) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
 | [Cross-database binding](/sql-plan-management.md#cross-database-binding) | Y | Y | N | N | N | N | N | N | N | N |
 | [Create bindings according to historical execution plans](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan) | Y | Y | Y | Y | E | N | N | N | N | N |

benchmark/benchmark-tidb-using-sysbench.md

@@ -20,7 +20,7 @@ server_configs:
     log.level: "error"
 ```
 
-It is also recommended to make sure [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610) is enabled and that you allow sysbench to use prepared statements by using `--db-ps-mode=auto`. See the [SQL Prepared Execution Plan Cache](/sql-prepared-plan-cache.md) for documentation about what the SQL plan cache does and how to monitor it.
+It is also recommended to make sure [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610) is enabled and that you allow sysbench to use prepared statements by using `--db-ps-mode=auto`. See the [SQL Prepared Execution Plan Cache](/sql-plan-cache.md) for documentation about what the SQL plan cache does and how to monitor it.
 
 > **Note:**
 >

latency-breakdown.md

@@ -66,7 +66,7 @@ e2e duration =
 
 - `tidb_server_get_token_duration_seconds` records the duration of Token waiting. This is usually less than 1 millisecond and is small enough to be ignored.
 - `tidb_session_parse_duration_seconds` records the duration of parsing SQL queries to an Abstract Syntax Tree (AST), which can be skipped by [`PREPARE/EXECUTE` statements](/develop/dev-guide-optimize-sql-best-practices.md#use-prepare).
-- `tidb_session_compile_duration_seconds` records the duration of compiling an AST to an execution plan, which can be skipped by [SQL prepared execution plan cache](/sql-prepared-plan-cache.md).
+- `tidb_session_compile_duration_seconds` records the duration of compiling an AST to an execution plan, which can be skipped by [SQL prepared execution plan cache](/sql-plan-cache.md).
 - `tidb_session_execute_duration_seconds{type="general"}` records the duration of execution, which mixes all types of user queries. This needs to be broken down into fine-grained durations for analyzing performance issues or bottlenecks.
 
 Generally, OLTP (Online Transactional Processing) workload can be divided into read and write queries, which share some critical code. The following sections describe latency in [read queries](#read-queries) and [write queries](#write-queries), which are executed differently.

optimizer-fix-controls.md

@@ -30,7 +30,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON';
 
 - Default value: `OFF`
 - Possible values: `ON`, `OFF`
-- This variable controls whether to allow plan cache for partitioned tables. If it is set to `ON`, neither [Prepared statement plan cache](/sql-prepared-plan-cache.md) nor [Non-prepared statement plan cache](/sql-non-prepared-plan-cache.md) will be enabled for [partitioned tables](/partitioned-table.md).
+- This variable controls whether to allow plan cache for partitioned tables. If it is set to `ON`, neither [Prepared statement plan cache](/sql-plan-cache.md) nor [Non-prepared statement plan cache](/sql-plan-cache.md) will be enabled for [partitioned tables](/partitioned-table.md).
 
 ### [`44262`](https://github.com/pingcap/tidb/issues/44262) <span class="version-mark">New in v6.5.3 and v7.2.0</span>
 

optimizer-hints.md

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

performance-tuning-methods.md

@@ -137,7 +137,7 @@ The diagrams of database time breakdown and execution time overview present both
 
 #### Query Per Second, Command Per Second, and Prepared-Plan-Cache
 
-By checking the following three panels in Performance Overview, you can learn the application workload type, how the application interacts with TiDB, and whether the application fully utilizes TiDB [prepared plan cache](/sql-prepared-plan-cache.md).
+By checking the following three panels in Performance Overview, you can learn the application workload type, how the application interacts with TiDB, and whether the application fully utilizes TiDB [prepared plan cache](/sql-plan-cache.md).
 
 - QPS: Short for Query Per Second. It shows the count of SQL statements executed by the application.
 - CPS By Type: Short for Command Per Second. Command indicates MySQL protocol-specific commands. A query statement can be sent to TiDB either by a query command or a prepared statement.
@@ -148,7 +148,7 @@ By checking the following three panels in Performance Overview, you can learn th
     - No prepared plan cache is hit: `avg-hit` (the number of hits per second) is 0, and `avg-miss` is equal to the number of `StmtExecute` commands per second. The possible reasons include:
         - The application is using the query interface.
         - The cached plans are cleaned up because the application calls the `StmtClose` command after each `StmtExecute` execution.
-        - All statements executed by `StmtExecute` do not meet the [cache conditions](/sql-prepared-plan-cache.md) so the execution plan cache cannot be hit.
+        - All statements executed by `StmtExecute` do not meet the [cache conditions](/sql-plan-cache.md) so the execution plan cache cannot be hit.
     - All prepared plan cache is hit: `avg-hit` (the number of hits per second) is equal to the number of `StmtExecute` commands per second, and `avg-miss` (the number without hits per second) is 0.
     - Some prepared plan cache is hit: `avg-hit` (the number of hits per second) is fewer than the number of `StmtExecute` commands per second. Prepared plan cache has known limitations. For example, it does not support subqueries, so SQL statements with subqueries cannot use prepared plan cache.
 

sql-optimization-concepts.md

@@ -14,4 +14,4 @@ After parsing the original query text by `parser` and some simple validity check
 
 Through these equivalent changes, this query becomes easier to handle in the logical execution plan. After the equivalent change is done, TiDB obtains a query plan structure equivalent to the original query, and then obtains a final execution plan based on the data distribution and the specific execution cost of an operator. For details, see [SQL Physical Optimization](/sql-physical-optimization.md).
 
-At the same time, when TiDB executes the [`PREPARE`](/sql-statements/sql-statement-prepare.md) statement, you can choose to enable caching to reduce the cost of generating the execution plan in TiDB. For details, see [Execution Plan Cache](/sql-prepared-plan-cache.md).
+At the same time, when TiDB executes the [`PREPARE`](/sql-statements/sql-statement-prepare.md) statement, you can choose to enable caching to reduce the cost of generating the execution plan in TiDB. For details, see [Execution Plan Cache](/sql-plan-cache.md).