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_intersectionUsing union(...)：并集合并，适用于OR连接的等值条件，结果为各索引主键的并集。例如
WHERE a=1 OR b=2Using 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) */提示，长期建议优先建合理联合索引，而非依赖合并。
