MySQL索引合并是优化器主动选择多个二级索引分别扫描再合并主键结果的访问方法，旨在减少回表次数和随机IO；适用于多独立条件命中不同二级索引的场景，包括intersect、union和sort_union三种策略。
MySQL索引合并（Index Merge）是查询优化器在单表多条件查询中，**主动选择多个二级索引分别扫描、再合并结果**的一种访问方法。它不依赖联合索引，也不跨表，核心目标是减少回表次数和随机IO——先用索引拿到主键，对主键归并排序，再一次性按序回表。
索引合并适用的典型场景
当WHERE子句包含多个独立条件，且每个条件都恰好命中不同二级索引时，优化器可能启用索引合并。常见组合包括：
-
等值+等值：如
WHERE f1 = 100 AND f2 = 200，f1和f2各有单独索引 -
等值+范围：如
WHERE status = 'active' AND create_time > '2024-01-01' -
多个OR条件：如
WHERE a = 1 OR b = 2（需满足ROR有序性要求）
注意：主键范围查询（如 id > 100）本身效率高，一般不会触发合并；若出现“本该走单索引却选了合并”，往往是统计信息不准或成本估算偏差所致。
三种合并方式与执行计划识别
MySQL支持三种索引合并策略，可通过EXPLAIN的Extra字段直接识别：
-
Using intersect(...)：交集合并，所有条件都是等值匹配，结果取各索引扫描主键的交集。例如
WHERE a=1 AND b=2，对应index_merge_intersection -
Using union(...)：并集合并，适用于OR连接的等值条件，结果为各索引主键的并集。例如
WHERE a=1 OR b=2 -
Using sort_union(...)：有序并集，用于OR连接中含范围条件的情况（如
a=1 OR b > 100），需额外排序主键再合并
关键细节：前两种（intersect/union）要求各索引扫描返回的主键天然有序（即满足ROR：Rowid-Ordered Retrieval），这通常要求索引字段在WHERE中是**完整、等值、无函数包裹**的匹配。
为什么能提升性能？背后的关键机制
索引合并不是简单拼数据，而是围绕主键做优化：
- 每个二级索引扫描只返回满足条件的主键值（不取整行），体积小、IO少
- 多个主键集合通过归并算法（非全量排序）快速合并，生成一个有序主键列表
- 最后按这个有序主键列表顺序回表——变成顺序IO，大幅降低磁盘寻道开销
相比单索引+全表过滤，它避免了大量无效记录的回表；相比联合索引缺失场景，它提供了无需改表结构的补救路径。
什么时候要警惕甚至禁用索引合并？
索引合并并非万能，实际中常因以下原因导致性能反降：
- 合并的索引太多（如超过3个），主键归并开销变大，CPU和内存压力上升
- 某个索引选择性极差（如
gender只有男/女两值），扫描出海量主键，拖慢整个合并流程 - 表数据量小（
- 统计信息过期，优化器低估单索引效率，错误倾向合并
临时禁用可在SQL中加/*+ NO_INDEX_MERGE(t1) */提示，长期建议优先建合理联合索引，而非依赖合并。
