在本篇文章中，我们聚焦于 MySQL 的索引合并概念、原理讲解与应用场景的全景解读。 通过示例和执行计划分析，帮助读者理解这种多索引协同的查询优化策略。
1. 索引合并到底是什么
核心定义：在 MySQL 的查询优化阶段，索引合并是一种在同一个查询中同时使用多张索引来筛选数据的策略。它不是简单地选择一个索引，而是让优化器并行或交替地访问多张索引后再归并结果。目标是提高筛选性、降低扫描成本，尤其当单一索引不足以快速定位记录时。
在实际场景中，索引合并常见于包含 OR 条件、或不同字段分别有独立索引的查询。如果仅使用单一索引，查询成本可能较高；通过合并两个或更多索引，理论上可以迅速筛选出符合条件的记录。
需要注意的是，并非所有查询都会从索引合并中受益，有时候额外的合并开销反而更大。因此，工程师应通过实际执行计划来判断是否启用该特性。
-- 示例：包含 OR 的查询
SELECT id FROM orders WHERE customer_id = 42 OR status = 'PENDING';
2. 工作原理与算法
2.1 工作原理概述
核心工作流程包括：候选索引集合的选取、对每个候选索引执行扫描、合并/去重结果、以及最终返回匹配行。优化器会在分析阶段评估每个索引的选择性，并决定是否同时用到多张索引。
这里涉及两种常见算法：并集（Union）与 交集（Intersection）。并集适合 OR 条件将多个索引的结果合并；交集在 AND 条件下利用两个索引的过滤条件来缩小候选集合。
2.2 算法类型与示例
并集算法适用于类似如下的查询：a = 1 OR b = 2，若 a、b 都有单独索引，优化器可能对两个索引分别扫描，然后对结果进行去重合并。在执行计划中常见“Index Merge Union”提示。
交集算法更适用于：a = 1 AND b = 2 或者某些范围条件配合复合索引。通过同时利用两个索引的过滤条件来缩小命中行数，然后进行排序与去重。具体是否使用取决于统计信息与代价估算。
-- 并集示例（假设有 idx_a(a) 和 idx_b(b)）
EXPLAIN SELECT id FROM t WHERE a = 1 OR b = 2;-- 交集示例
EXPLAIN SELECT id FROM t WHERE a = 1 AND b = 2;
3. 应用场景与案例
3.1 典型应用场景
最常见的是包含 OR 的查询：哪一个条件命中就返回哪一部分结果。如果两个条件分别由不同索引支撑，索引合并可以避免走慢的全表扫描。尤其在大表和高基数列上更有效。
另一类场景是组合条件较复杂的查询：多个列存在独立的索引，且查询要在不同条件之间做切换。此时，优化器会评估是否用“Index Merge Union/Intersection”来优化，而不是简单地退回到单一索引。
3.2 典型查询示例
示例 1：对订单表进行筛选，需要同时考虑下列条件中的任意一个：客户ID、订单状态、创建时间窗口，若这些列各自有独立索引，索引合并可能提升性能。
示例 2：产品表需要根据分类和价格筛选，且两个条件各自有独立索引，若两者符合 AND 条件，索引合并的交集算法可能帮助更快定位结果。
-- 示例 1：OR 条件
SELECT order_id, customer_id, status FROM orders
WHERE customer_id = 123 OR status = 'SHIPPED';-- 示例 2：AND 条件配合独立索引
SELECT product_id, name FROM products
WHERE category_id = 5 AND price BETWEEN 50 AND 100;
4. 实践中的观测与优化
4.1 如何通过执行计划观测索引合并
要验证是否真的使用了索引合并，需要查看执行计划。EXPLAIN 语句提供了“Index Merge”相关信息，如 “Index Merge Union”、“Index Merge Intersection” 等字样。通过对比不同版本的执行计划，可以判断是否被启用。
在 MySQL 版本较新的实现中，如果索引可用且代价较小，优化器会自动选择索引合并，否则会回退到单一索引或全表扫描。
4.2 影响因素与调优要点
影响因素包括：索引的选择性、列的基数、数据分布、表的大小以及联合查询的结构。若单列索引的基数太低，合并后的成本可能高于单一索引的直接筛选。
常见的调优做法有：创建相关的独立索引，避免把两个条件完全放在同一个复合索引中，以便优化器有机会独立评估每个索引的代价；同时可以使用 USE INDEX 或 FORCE INDEX 提示来引导优化器尝试多索引合并的路径。注意要以实际执行计划为准。
-- 使用 USE INDEX 提示保留两个索引供合并
SELECT id FROM t
WHERE a = 1 OR b = 2
USE INDEX (idx_a, idx_b);-- 强制索引使用（谨慎）
SELECT /*+ FORCE_INDEX(t, idx_a, idx_b) */ id FROM t
WHERE a = 1 OR b = 2;
5. 相关注意点与限制
5.1 版本与引擎对索引合并的影响
不同 MySQL 版本对索引合并的支持和优化策略不同。在 InnoDB、MyISAM 等存储引擎中，索引合并的实现存在差异，新版本通常对统计信息与代价模型进行了改进。
如果你使用的是早期版本，可能需要通过参数开启：optimizer_switch=IndexMerge=on等配置项，但在现代版本中往往已默认开启或表现更佳。
5.2 与单一索引的权衡
在某些场景下，索引合并并不优于单一索引。合并开销、去重成本以及内存占用等因素都可能抵消潜在收益。因此，建议通过 EXPLAIN 实测再决定是否开启。
