MySQL 在无合适联合索引且 WHERE 含 OR 或 AND 多列等值条件时触发索引合并；它先分别扫描多个单列索引，再合并结果，I/O 与 CPU 开销大，通常比联合索引慢 3–10 倍。
MySQL 什么时候会触发索引合并（Index Merge）？
MySQL 的
是优化器在单表查询中，对多个单列索引进行并行扫描并合并结果的策略，**仅当没有合适的联合索引、且 WHERE 条件含 OR 或 AND 多列等值条件时才可能启用**。它不是“自动加速神器”，反而是性能隐患信号——说明索引设计存在缺陷。
常见触发场景：
（
和
同时存在）
（无
，但有
和
）
（部分条件下也可能走 Index Merge）
可通过
观察
列是否为
，
列显示多个索引名（如
），
中出现
或
。
为什么 Index Merge 通常比联合索引慢？
因为它是“事后合并”：MySQL 先分别扫描多个索引得到各自 ID 集合，再做交集/并集运算（常需临时表或文件排序），最后回表取数据。相比单次 B+ 树遍历的联合索引，I/O 和 CPU 开销都更高。
关键瓶颈点：
多次随机 I/O 扫描不同索引树
内存中集合运算（尤其大结果集时触发磁盘临时表）
无法利用最左前缀原则跳过排序，
或
效率骤降
优化器成本估算不准，有时误选 Index Merge 而非更优的全表扫描
实测中，同等数据量下，
查询
比
+
触发 Index Merge 快 3–10 倍，且稳定性高。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
如何避免 Index Merge 并真正提升性能？
核心思路是让优化器“别无选择”——用覆盖性联合索引替代多个单列索引，并控制索引宽度。
操作建议：
把高频组合查询条件转为联合索引，按「等值 → 最左前缀 → 范围」顺序
排列
，例如：
→ 建
删除冗余单列索引，比如已有
，再单独建
通常无意义（除非
单独查询极频繁且
列很大）
对
条件，优先改写 SQL（如拆成
）或补全联合索引；若必须保留，可加
引导走主键或合适索引，避开 Index Merge
用
或
分析真实查询中的索引使用率，避免“为 OR 而建索引”的惯性思维
哪些情况 Index Merge 反而合理？
极少，但存在：当表极大、单列索引非常窄（如 TINYINT）、且 OR 条件两边结果集都很小（
此时应：
确认
中各分支的
确实很小
检查
和
状态变量，验证是否真为顺序扫描而非大量随机回表
不盲目禁止，但需记录该例外，并在注释中说明原因
真正难处理的从来不是 Index Merge 本身，而是业务查询模式和索引设计长期脱节——一个没被
过滤、却常年霸占
输出的索引，才是最该删掉的那个。
Index MergeWHERE a = 1 OR b = 2INDEX(a)INDEX(b)WHERE a = 1 AND b = 2INDEX(a,b)INDEX(a)INDEX(b)WHERE a IN (1,2) AND b > 10EXPLAINtypeindex_mergekeya,bExtraUsing union(...)Using sort_union(...)ORDER BYLIMITINDEX(a,b)WHERE a=1 AND b=2INDEX(a)INDEX(b)WHERE status = 'active' AND category_id = 5 AND created_at > '2023-01-01'INDEX(status, category_id, created_at)INDEX(a,b)INDEX(a)abORUNION ALLFORCE INDEXSELECT ... INTO DUMPFILEpt-index-usageALTER TABLE orders
DROP INDEX idx_status,
DROP INDEX idx_category_id,
ADD INDEX idx_status_category_created (status, category_id, created_at);EXPLAIN FORMAT=JSONrowshandler_read_nexthandler_read_rnd_nextWHERESHOW CREATE TABLE