mysql中索引合并与性能提升技巧

来源：这里教程网时间：2026-02-28 20:42:27 作者：

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 倍，且稳定性高。

如何避免 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);