MySQL 在无合适联合索引且 WHERE 含 OR 或 AND 多列等值条件时触发索引合并；它先分别扫描多个单列索引，再合并结果，I/O 与 CPU 开销大，通常比联合索引慢 3–10 倍。
MySQL 什么时候会触发索引合并（Index Merge）？
MySQL 的 Index Merge 是优化器在单表查询中，对多个单列索引进行并行扫描并合并结果的策略，**仅当没有合适的联合索引、且 WHERE 条件含 OR 或 AND 多列等值条件时才可能启用**。它不是“自动加速神器”，反而是性能隐患信号——说明索引设计存在缺陷。
常见触发场景：
-
WHERE a = 1 OR b = 2（INDEX(a)和INDEX(b)同时存在） -
WHERE a = 1 AND b = 2（无INDEX(a,b)，但有INDEX(a)和INDEX(b)） -
WHERE a IN (1,2) AND b > 10（部分条件下也可能走 Index Merge）
可通过 EXPLAIN 观察 type 列是否为 index_merge，key 列显示多个索引名（如 a,b），Extra 中出现 Using union(...) 或 Using sort_union(...)。
为什么 Index Merge 通常比联合索引慢？
因为它是“事后合并”：MySQL 先分别扫描多个索引得到各自 ID 集合，再做交集/并集运算（常需临时表或文件排序），最后回表取数据。相比单次 B+ 树遍历的联合索引，I/O 和 CPU 开销都更高。
关键瓶颈点：
- 多次随机 I/O 扫描不同索引树
- 内存中集合运算（尤其大结果集时触发磁盘临时表）
- 无法利用最左前缀原则跳过排序，
ORDER BY或LIMIT效率骤降 - 优化器成本估算不准，有时误选 Index Merge 而非更优的全表扫描
实测中，同等数据量下，INDEX(a,b) 查询 WHERE a=1 AND b=2 比 INDEX(a)+INDEX(b) 触发 Index Merge 快 3–10 倍，且稳定性高。
Yes!Sun基于PHP+MYSQL技术，体积小巧、应用灵活、功能强大，是一款为企业网站量身打造的WEB系统。其创新的设计理念，为企业网的开发设计及使用带来了全新的体验：支持前沿技术：动态缓存、伪静态、静态生成、友好URL、SEO设置等提升网站性能、用户体验、搜索引擎友好度的技术均为Yes!Sun所支持。易于二次开发：采用独创的平台化理念，按需定制项目中的各种元素，如：产品属性、产品相册、新闻列表
如何避免 Index Merge 并真正提升性能？
核心思路是让优化器“别无选择”——用覆盖性联合索引替代多个单列索引，并控制索引宽度。
操作建议：
- 把高频组合查询条件转为联合索引，按「等值 → 最左前缀 → 范围」顺序排列，例如：
WHERE status = 'active' AND category_id = 5 AND created_at > '2023-01-01'→ 建INDEX(status, category_id, created_at) - 删除冗余单列索引，比如已有
INDEX(a,b)，再单独建INDEX(a)通常无意义（除非a单独查询极频繁且b列很大） - 对
OR条件，优先改写 SQL（如拆成UNION ALL）或补全联合索引；若必须保留，可加FORCE INDEX引导走主键或合适索引，避开 Index Merge - 用
SELECT ... INTO DUMPFILE或pt-index-usage分析真实查询中的索引使用率，避免“为 OR 而建索引”的惯性思维
ALTER TABLE orders DROP INDEX idx_status, DROP INDEX idx_category_id, ADD INDEX idx_status_category_created (status, category_id, created_at);
哪些情况 Index Merge 反而合理？
极少，但存在：当表极大、单列索引非常窄（如 TINYINT）、且 OR 条件两边结果集都很小（
此时应：
- 确认
EXPLAIN FORMAT=JSON中各分支的rows确实很小 - 检查
handler_read_next和handler_read_rnd_next状态变量，验证是否真为顺序扫描而非大量随机回表 - 不盲目禁止，但需记录该例外，并在注释中说明原因
真正难处理的从来不是 Index Merge 本身，而是业务查询模式和索引设计长期脱节——一个没被 WHERE 过滤、却常年霸占 SHOW CREATE TABLE 输出的索引，才是最该删掉的那个。
