在MySQL的查询优化体系中，索引合并（Index Merge）是一个经常被低估却非常实用的特性。很多开发者在表中为多个列分别建立了单列索引，当查询条件同时命中这些列时，往往会疑惑：数据库到底会选哪个索引？实际上，优化器可能一个都不放弃，而是通过索引合并机制同时利用多个索引，将各自的结果集进行交集或并集运算后再返回数据。理解这一机制，不仅能解释很多执行计划中的怪异现象，还能指导我们做出更合理的索引设计。
什么是索引合并，为什么需要它
索引合并是MySQL在执行一条查询时，同时对多个索引进行范围扫描或精确定位，并将各自得到的主键集合做二次运算的一种访问方式。它在执行计划中体现为type列的值为index_merge。典型场景是：表中存在idx_a和idx_b两个单列索引，查询条件为WHERE a=1 AND b=2，优化器可能分别通过两个索引找到满足条件的主键集合，然后求交集。
之所以需要这个机制，是因为单列索引存在天然瓶颈。如果只在a列上建索引，那么b=2这个条件只能在回表后逐行过滤；反之亦然。当a=1匹配的行数非常多而b=2匹配的行数很少时，只走a索引的代价会很高。索引合并允许优化器同时利用两个索引的过滤能力，大幅减少最终需要回表校验的行数。
可以用下面的SQL来观察索引合并是否被触发：
EXPLAIN SELECT * FROM orders WHERE customer_id = 1001 AND order_status = 3; -- 执行计划中可能出现： -- type: index_merge -- key: idx_customer,idx_status -- Extra: Using intersect(idx_customer,idx_status)
三种合并算法的原理与适用条件
索引合并并非只有一种工作方式，MySQL实现了三种算法，分别对应不同的查询形态。第一种是index_merge_intersection，即交集合并，适用于多个条件之间是AND关系的情况。它要求每个索引都能独立完成等值查询或主键范围查询，然后对得到的主键有序集合求交集。由于InnoDB的二级索引叶子节点存储的是主键值，且返回时天然按主键有序，求交集的效率相当高，类似归并操作。
第二种是index_merge_union，即并集合并，适用于OR连接的多个条件。例如WHERE a=1 OR b=2，优化器分别扫描两个索引，把结果按主键去重合并。第三种是sort_union则是对union的补充，当索引扫描结果不是按主键有序时（比如条件是范围查询a>100 OR b<50），需要先把各索引扫描到的主键排序去重，再统一回表。可以简单理解为：intersection和union处理能精确定位的场景，sort_union处理范围扫描场景。
-- 并集合并示例 EXPLAIN SELECT * FROM orders WHERE customer_id = 1001 OR order_no = 'SO20240001'; -- Extra: Using union(idx_customer,PRIMARY) -- sort_union 示例 EXPLAIN SELECT * FROM orders WHERE customer_id > 1000 OR order_no < 'SO20240010'; -- Extra: Using sort_union(idx_customer,idx_order_no)
索引合并什么时候是坑
虽然索引合并看起来很美好，但它并不总是最优解，甚至可能是性能杀手。核心问题在于回表次数。intersection合并时，每个索引都要完成一次完整的扫描，得到的主键交集如果有N行，就需要回表N次；而如果把这N个主键直接包含在一个联合索引中，只需要一次顺序读取。当两个单列索引的选择性都不高时，比如各匹配几十万行，交集运算本身的成本加上大量随机IO，可能远不如全表扫描或只走其中一个索引。
另一个常见坑是优化器错误地选择了合并。在某些数据分布下，优化器基于统计信息估算的行数与实际偏差很大，导致它选择了看似合理实则低效的index_merge计划，表现为查询突然变慢。此时可以通过优化器开关强制关闭索引合并来验证：
-- 会话级别关闭索引合并，用于对比测试 SET SESSION optimizer_switch='index_merge_intersection=off'; SET SESSION optimizer_switch='index_merge_union=off'; -- 或者使用提示强制走某个索引 SELECT * FROM orders WHERE customer_id = 1001 AND order_status = 3;
此外要注意，索引合并对条件形式有严格要求。如果某一侧的条件无法使用索引（例如对列做了函数运算、隐式类型转换），合并就不会发生。OR条件中只要有一个分支没索引，整个查询就会退化为全表扫描，这是比索引合并失效更常见的性能问题。
从索引设计角度根治单列索引瓶颈
索引合并本质上是一种运行时补救措施，真正的最优解是在索引设计阶段就把高频组合查询固化成联合索引。把上面例子中的customer_id和order_status建成联合索引idx_cust_status(customer_id, order_status)，查询就变成单纯的范围定位加顺序读取，执行计划中的type会提升为ref，回表次数等于最终结果行数，不再有多索引扫描和集合运算的开销。
设计联合索引时需要遵循最左前缀原则，把等值查询的列放在前面，范围查询的列放在后面，同时优先考虑区分度高的列。这样不仅覆盖了组合查询，前缀列上的单独查询也能复用该索引。可以通过查询索引使用统计来评估现有索引的利用情况，删除冗余的单列索引，减少索引维护成本：
-- 查看索引使用情况 SELECT * FROM sys.schema_unused_indexes WHERE object_schema = 'mydb'; -- 建立联合索引替代两个单列索引 ALTER TABLE orders ADD INDEX idx_cust_status(customer_id, order_status), DROP INDEX idx_customer, DROP INDEX idx_status;
总结来看，索引合并是优化器在索引设计不理想时的一种自我拯救，值得理解但不应依赖。生产环境中如果频繁在慢查询日志里看到Using intersect或Using sort_union，这通常是一个明确信号：表缺少合适的联合索引。把功夫下在索引设计上，让索引合并无用武之地，才是性能优化的正道。
索引合并Index MergeMySQL优化修改时间：2026-09-01 15:32:46