INDEX MERGE 有时比联合索引慢，因其需分别扫描多个索引、取交集/并集、去重排序及回表，开销大且受数据分布、选择性及优化器成本估算影响；而联合索引一次B+树遍历即可定位，更稳定高效。
为什么 INDEX MERGE 有时比联合索引还慢？
MySQL 的 INDEX MERGE 确实能在没有覆盖联合索引时“凑合用”，但它不是银弹。优化器只在特定条件下启用，且合并过程本身有开销：多个索引分别扫描 → 结果集取交集/并集 → 去重/排序 → 回表。一旦数据量上升或条件复杂，EXPLAIN 中出现 index_merge 并不意味着更快，反而可能比全表扫描还糟。
常见错误现象：EXPLAIN 显示 type: index_merge，但查询耗时飙升；key 列列出多个索引名（如 key: idx_a,idx_b），却没走预想的联合索引。
- 触发前提苛刻：各单列索引必须能独立过滤出较小子集（比如
WHERE a = 1 AND b > 100中，a是等值，b是范围，才可能触发sort_union或intersect） - 不支持
LIKE '%xxx'这类无法使用索引的条件参与合并 - 如果其中任一索引选择性极差（比如性别字段建了索引），优化器大概率直接放弃
INDEX MERGE - 5.6+ 支持
INDEX MERGE，但 8.0.19+ 默认关闭optimizer_switch='index_merge=off'，需手动开启
EXPLAIN 里看到 index_merge 怎么确认它真在干活？
别光看 type 列。真正判断是否生效，得盯住 key 和 rows，再结合 Extra 字段交叉验证。
使用场景：你加了 idx_status 和 idx_created_at，执行 SELECT * FROM orders WHERE status = 'paid' AND created_at > '2024-01-01'，想确认 MySQL 是否真的合并用了这两个索引。
-
key: idx_status,idx_created_at是必要信号，但还不够 -
Extra必须含Using intersect(idx_status,idx_created_at)或Using union(...)—— 这才是铁证 -
rows应明显小于单用任一索引时的预估行数（比如单用idx_status预估 10 万行，合并后降到 2 万，才算有效） - 用
SELECT @@optimizer_switch检查index_merge是否启用，避免白调
什么时候该删掉单列索引、改用联合索引？
只要 WHERE 条件里固定出现两个或以上字段组合，且顺序合理，联合索引几乎总是优于 INDEX MERGE。因为一次 B+ 树遍历就能定位，不用合并、去重、额外回表。
参数差异关键在「最左前缀」和「等值优先」：比如常查 WHERE category = ? AND status = ? AND created_at > ?，联合索引应建为 (category, status, created_at)，而不是 (created_at, category, status) —— 后者无法利用 created_at 的范围查询加速前面的等值匹配。
- 等值条件（
=、IN）放左边，范围条件（>、BETWEEN、LIKE 'abc%'）放右边 - 高选择性字段（如用户 ID）优先于低选择性字段（如状态码）放在左侧
- 如果已有单列索引
idx_a和idx_b，又新增联合索引(a,b)，通常可安全删掉idx_a（因前缀可用），但idx_b是否保留，取决于是否有单独查b的语句 -
ORDER BY字段若也在 WHERE 中，尽量纳入联合索引末尾，避免额外排序
复合查询中 INDEX MERGE 和联合索引谁先被选中？
优化器按成本估算选，不是按“谁更高级”选。即使你建了联合索引，只要优化器算出来单列索引合并的成本更低（比如统计信息不准、数据分布倾斜），它就敢弃联合索引而用 INDEX MERGE。
性能影响很实际：联合索引稳定、可控；INDEX MERGE 成本波动大，尤其当某列数据倾斜（比如 95% 的记录 status = 'pending'），优化器可能误判其选择性，导致计划退化。
- 用
ANALYZE TABLE更新统计信息，让优化器“看清”真实分布 - 对关键查询加
FORCE INDEX锁定联合索引，防止意外走INDEX MERGE（例如SELECT * FROM t FORCE INDEX (idx_a_b) WHERE a=1 AND b>10） - 监控
Handler_read_next和Handler_read_key的差值：差值越大，说明索引扫描越“绕路”，可能是INDEX MERGE在反复跳转 - 注意：联合索引无法覆盖的查询（比如
SELECT c FROM t WHERE a=1 AND b=2，但索引是(a,b)），仍需回表 —— 这点和INDEX MERGE的回表开销本质相同，别以为建了联合索引就一定免回表
真正难的不是知道该建什么索引，而是理解优化器怎么权衡——它看的是成本模型，不是你的直觉。哪怕一条 SQL 看起来“显然该走联合索引”，只要统计信息滞后或配置开关关着，它就可能拐个弯去合并单列索引。
