update doc for IndexMerge GA

explain-index-merge.md

@@ -5,19 +5,18 @@ summary: Learn about the execution plan information returned by the `EXPLAIN` st
 
 # Explain Statements Using Index Merge
 
-`IndexMerge` is a method introduced in TiDB v4.0 to access tables. Using this method, the TiDB optimizer can use multiple indexes per table and merge the results returned by each index. In some scenarios, this method makes the query more efficient by avoiding full table scans.
+Index Merge is a method introduced in TiDB v4.0 to access tables. Using this method, the TiDB optimizer can use multiple indexes per table and merge the results returned by each index. In some scenarios, this method makes the query more efficient by avoiding full table scans.
 
 ```sql
-mysql> EXPLAIN SELECT * from t where a = 1 or b = 1;
+mysql> EXPLAIN SELECT * FROM t WHERE a = 1 or b = 1;
 +-------------------------+----------+-----------+---------------+--------------------------------------+
 | id                      | estRows  | task      | access object | operator info                        |
 +-------------------------+----------+-----------+---------------+--------------------------------------+
 | TableReader_7           | 8000.00  | root      |               | data:Selection_6                     |
 | └─Selection_6           | 8000.00  | cop[tikv] |               | or(eq(test.t.a, 1), eq(test.t.b, 1)) |
 |   └─TableFullScan_5     | 10000.00 | cop[tikv] | table:t       | keep order:false, stats:pseudo       |
 +-------------------------+----------+-----------+---------------+--------------------------------------+
-mysql> set @@tidb_enable_index_merge = 1;
-mysql> explain select * from t use index(idx_a, idx_b) where a > 1 or b > 1;
+EXPLAIN SELECT /*+ USE_INDEX_MERGE(t) */ * FROM t WHERE a > 1 OR b > 1;
 +--------------------------------+---------+-----------+-------------------------+------------------------------------------------+
 | id                             | estRows | task      | access object           | operator info                                  |
 +--------------------------------+---------+-----------+-------------------------+------------------------------------------------+
@@ -28,18 +27,18 @@ mysql> explain select * from t use index(idx_a, idx_b) where a > 1 or b > 1;
 +--------------------------------+---------+-----------+-------------------------+------------------------------------------------+
 ```
 
-In the above query, the filter condition is a `WHERE` clause that uses `OR` as the connector. Without `IndexMerge`, you can use only one index per table. `a = 1` cannot be pushed down to the index `a`; neither can `b = 1` be pushed down to the index `b`. The full table scan is inefficient when a huge volume of data exists in `t`. To handle such a scenario, `IndexMerge` is introduced in TiDB to access tables.
+In the above query, the filter condition is a `WHERE` clause that uses `OR` as the connector. Without Index Merge, you can use only one index per table. `a = 1` cannot be pushed down to the index `a`; neither can `b = 1` be pushed down to the index `b`. The full table scan is inefficient when a huge volume of data exists in `t`. To handle such a scenario, Index Merge is introduced in TiDB to access tables.
 
-`IndexMerge` allows the optimizer to use multiple indexes per table, and merge the results returned by each index to generate the execution plan of the latter `IndexMerge` in the figure above. Here the `IndexMerge_16` operator has three child nodes, among which `IndexRangeScan_13` and `IndexRangeScan_14` get all the `RowID`s that meet the conditions based on the result of range scan, and then the `TableRowIDScan_15` operator accurately reads all the data that meets the conditions according to these `RowID`s.
+Index Merge allows the optimizer to use multiple indexes per table, and merge the results returned by each index to generate the execution plan of the latter `IndexMerge` in the figure above. Here the `IndexMerge_16` operator has three child nodes, among which `IndexRangeScan_13` and `IndexRangeScan_14` get all the `RowID`s that meet the conditions based on the result of range scan, and then the `TableRowIDScan_15` operator accurately reads all the data that meets the conditions according to these `RowID`s.
 
 For the scan operation that is performed on a specific range of data, such as `IndexRangeScan`/`TableRangeScan`, the `operator info` column in the result has additional information about the scan range compared with other scan operations like `IndexFullScan`/`TableFullScan`. In the above example, the `range:(1,+inf]` in the `IndexRangeScan_13` operator indicates that the operator scans the data from 1 to positive infinity.
 
 > **Note:**
 >
-> At present, the `IndexMerge` feature is disabled by default in TiDB 4.0.0-rc.1. In addition, the currently supported scenarios of `IndexMerge` in TiDB 4.0 are limited to the disjunctive normal form (expressions connected by `or`). The conjunctive normal form (expressions connected by `and`) will be supported in later versions. Enable the `IndexMerge` in one of two ways:
+> - The Index Merge feature is enabled by default in TiDB 5.4.0 and later versions. That is, [`tidb_enable_index_merge`](/system-variables.md#tidb_enable_index_merge-new-in-v40) is `ON`.
 >
-> - Set `tidb_enable_index_merge=1`;
+> - When the SQL Hint [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-) is used, Index Merge is enabled mandatorily, regardless of the setting of `tidb_enable_index_merge`. To enable Index Merge when the filtering conditions contain expressions that cannot be pushed down, use SQL Hint [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-).
 >
-> - Use the SQL Hint [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-) in the query.
+> - Index Merge supports only disjunctive normal forms (DNFs, expressions connected by `or`) and does not support conjunctive normal forms (CNFs, expressions connected by `and`).
 >
-> SQL Hint has a higher priority than system variables.
+> - Index Merge is not applicable to temporary tables.

optimizer-hints.md

@@ -262,7 +262,9 @@ In addition to this hint, setting the `tidb_enable_index_merge` system variable
 
 > **Note:**
 >
-> `NO_INDEX_MERGE` has a higher priority over `USE_INDEX_MERGE`. When both hints are used, `USE_INDEX_MERGE` does not take effect.
+> - `NO_INDEX_MERGE` has a higher priority over `USE_INDEX_MERGE`. When both hints are used, `USE_INDEX_MERGE` does not take effect.
+>
+> - If subqueries exist, `NO_INDEX_MERGE` takes effect only when used in the outer query.
 
 ### USE_TOJA(boolean_value)
 

system-variables.md

@@ -742,8 +742,16 @@ Constraint checking is always performed in place for pessimistic transactions (d
 ### tidb_enable_index_merge <span class="version-mark">New in v4.0</span>
 
 - Scope: SESSION | GLOBAL
-- Default value: `OFF`
-- This variable is used to control whether to enable the index merge feature.
+- Default value: `ON`
+- This variable is used to control whether to enable the Index Merge feature.
+
+> **Note:**
+>
+> - When upgrading a TiDB cluster from versions earlier than v4.0.0 to v5.4.0 or later, this variable is disabled by default to prevent rollback due to any plan change.
+>
+> - When upgrading a TiDB cluster from v4.0.0 or later to v5.4.0 or later, this variable remains the setting before the upgrade.
+>
+> - For TiDB clusters of v5.4.0 and later versions, this variable is enabled by default.
 
 ### tidb_enable_list_partition <span class="version-mark">New in v5.0</span>