MySQL索引合并是优化器在单表多条件查询中权衡成本后启用的妥协策略，常见于OR（union）或AND（intersection）连接且各条件有独立索引时，但性能常不如联合索引。
MySQL 会自动触发索引合并（Index Merge），当且仅当：单表查询的 WHERE 条件中存在多个独立可索引的子条件，且优化器估算走单个索引的成本高于合并多个索引扫描结果的成本。 它不是“能用就用”，而是权衡后的妥协选择——尤其在缺少合适联合索引时才露面。强行依赖它，往往意味着索引设计有缺口。
哪些 WHERE 条件组合可能触发 index_merge_union
这是最常见的索引合并类型，对应 EXPLAIN 的 Extra: Using union(...)。典型场景是 OR 连接、各分支字段均有独立索引：
-
WHERE age = 25 OR city = 'Beijing'，且age和city各自建了单列索引 -
WHERE status = 'active' OR type IN ('A', 'B')，两个字段都有索引，且type索引支持range扫描 - 注意：如果其中某个条件能走
const或eq_ref（比如主键等值），优化器大概率放弃合并，直接走那个最优索引 - 若
OR中混入函数、隐式转换或不等号（如age > 25 OR city = 'Beijing'），index_merge_union仍可能启用，但index_merge_sort_union更常见（需额外排序）
什么条件下会走 index_merge_intersection
对应 Extra: Using intersect(...)，本质是求多个索引结果的主键交集，要求更严格：
- WHERE 必须是
AND连接，且每个子条件都使用独立索引的**完整前缀等值匹配** - 例如索引
idx_user_id和idx_status存在，则WHERE user_id = 123 AND status = 'paid'可能触发 - 但若有一个索引是联合索引
idx_user_id_status，而你只用user_id = 123，那它不会参与 intersection —— 因为该索引未被“完全等值命中” - 数据分布影响大：如果任一条件返回的主键数量很大（比如
status = 'pending'匹配 80% 行），优化器通常认为交集计算+回表不如直接扫联合索引或全表
为什么有时 explain 显示 index_merge 却性能更差
索引合并不是银弹，实际慢于单索引的情况很常见，原因集中在三处：
- 合并本身有开销：多个索引分别扫描 → 主键归并（
QUICK_ROR_INTERSECT_SELECT类需保持主键有序；QUICK_INDEX_MERGE_SELECT类要额外排序）→ 去重/交集计算 → 最终回表。每一步都吃 CPU 和临时内存 - 回表放大效应：假设
index_merge_union从两个索引各取 1 万主键，合并后剩 1.5 万，但你要查SELECT *，就得回表 1.5 万次随机 IO —— 而一个覆盖索引可能只要顺序读几百页 - 统计信息不准：MySQL 依赖表的行数、索引基数（cardinality）估算成本。若
ANALYZE TABLE没更新，或数据倾斜严重（如status99% 是 'active'），优化器会误判合并更优 - 小数据量干扰：测试时只插了几百行，优化器发现合并和全表扫描成本接近，可能随意选一个；务必用真实量级（如 10 万+ 行）验证
如何判断是否该干预 index_merge 行为
核心原则：**优先补联合索引，而非调优合并开关。** 但当必须干预时：
- 先确认问题：用
EXPLAIN FORMAT=JSON查看query_cost和各索引的rows_examined_per_scan，对比关闭合并后的成本（SET optimizer_switch='index_merge=off'; EXPLAIN ...） - 禁用某类合并：如确定
intersection总是劣于联合索引，可关掉SET optimizer_switch='index_merge_intersection=off'; - 强制走某索引：用
USE INDEX (idx_name)或FORCE INDEX，但注意这会绕过优化器，后续数据分布变化可能导致更差表现 - 最稳解法：把
WHERE a = ? AND b = ?对应的两个单列索引，换成联合索引KEY idx_a_b (a, b)—— 这样既避免合并，又天然支持索引覆盖
真正容易被忽略的是：索引合并的“合并”动作发生在存储引擎层，但结果集排序（如 ORDER BY created_at LIMIT 10）仍在 server 层做。这意味着即使索引本身有序，合并后的主键流也不保证业务字段顺序——你依然逃不开 filesort。这时候，ORDER BY 字段是否包含在联合索引最右位，才是决定性能的关键。
