planner: update Plan Cache doc (#16771)

choose-index.md

@@ -404,3 +404,75 @@ mysql> EXPLAIN SELECT /*+ use_index_merge(t3, idx) */ * FROM t3 WHERE ((1 member
 +-------------------------+----------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 3 rows in set, 2 warnings (0.00 sec)
 ```
+
+### Multi-valued indexes and plan cache
+
+A query plan that uses `member of` to choose multi-valued indexes can be cached. A query plan that uses the `JSON_CONTAINS()` or `JSON_OVERLAPS()` function to choose multi-valued indexes cannot be cached.
+
+The following are some examples that query plans can be cached:
+
+```sql
+mysql> CREATE TABLE t5 (j1 JSON, j2 JSON, INDEX idx1((CAST(j1 AS SIGNED ARRAY))));
+Query OK, 0 rows affected (0.04 sec)
+
+mysql> PREPARE st FROM 'SELECT /*+ use_index(t5, idx1) */ * FROM t5 WHERE (? member of (j1))';
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> SET @a=1;
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> EXECUTE st USING @a;
+Empty set (0.01 sec)
+
+mysql> EXECUTE st USING @a;
+Empty set (0.00 sec)
+
+mysql> SELECT @@last_plan_from_cache;
++------------------------+
+| @@last_plan_from_cache |
++------------------------+
+|                      1 |
++------------------------+
+1 row in set (0.00 sec)
+
+mysql> PREPARE st FROM 'SELECT /*+ use_index(t5, idx1) */ * FROM t5 WHERE (? member of (j1)) AND JSON_CONTAINS(j2, ?)';
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> SET @a=1, @b='[1,2]';
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> EXECUTE st USING @a, @b;
+Empty set (0.00 sec)
+
+mysql> EXECUTE st USING @a, @b;
+Empty set (0.00 sec)
+
+mysql> SELECT @@LAST_PLAN_FROM_CACHE; -- can hit plan cache if the JSON_CONTAINS doesn't impact index selection
++------------------------+
+| @@LAST_PLAN_FROM_CACHE |
++------------------------+
+|                      1 |
++------------------------+
+1 row in set (0.00 sec)
+```
+
+The following are some examples that query plans cannot be cached:
+
+```sql
+mysql> PREPARE st2 FROM 'SELECT /*+ use_index(t5, idx1) */ * FROM t5 WHERE JSON_CONTAINS(j1, ?)';
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> SET @a='[1,2]';
+Query OK, 0 rows affected (0.01 sec)
+
+mysql> EXECUTE st2 USING @a;
+Empty set, 1 warning (0.00 sec)
+
+mysql> SHOW WARNINGS;  -- cannot hit plan cache since the JSON_CONTAINS predicate might affect index selection
++---------+------+-------------------------------------------------------------------------------------------------------+
+| Level   | Code | Message                                                                                               |
++---------+------+-------------------------------------------------------------------------------------------------------+
+| Warning | 1105 | skip prepared plan-cache: json_contains function with immutable parameters can affect index selection |
++---------+------+-------------------------------------------------------------------------------------------------------+
+1 row in set (0.01 sec)
+```

sql-prepared-plan-cache.md

@@ -20,7 +20,7 @@ TiDB also supports execution plan caching for some non-`PREPARE` statements, sim
 In the current version of TiDB, if a `Prepare` statement meets any of the following conditions, the query or the plan is not cached:
 
 - The query contains SQL statements other than `SELECT`, `UPDATE`, `INSERT`, `DELETE`, `Union`, `Intersect`, and `Except`.
-- The query accesses partitioned tables or temporary tables, or a table that contains generated columns.
+- The query accesses partitioned tables or temporary tables.
 - The query contains non-correlated sub-queries, such as `SELECT * FROM t1 WHERE t1.a > (SELECT 1 FROM t2 WHERE t2.b < 1)`.
 - The query contains correlated sub-queries with `PhysicalApply` operators in the execution plan, such as `SELECT * FROM t1 WHERE t1.a > (SELECT a FROM t2 WHERE t1.b > t2.b)`.
 - The query contains the `ignore_plan_cache` or `set_var` hint, such as `SELECT /*+ ignore_plan_cache() */ * FROM t` or `SELECT /*+ set_var(max_execution_time=1) */ * FROM t`.