mysql执行计划中的UsingMerge是什么_分析索引合并的利弊

Using merge：MySQL执行计划里的一个“警示灯”

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在MySQL的性能诊断中，Using merge 绝对是一个值得你高度关注的信号。它本身并非一种索引类型，而是执行计划里一个明确的“警示灯”：它意味着优化器放弃了使用单一高效索引的路径，转而选择同时动用多个单列索引，并在内存中进行结果的交集或并集运算。这通常暗示着表上可能缺少一个“恰到好处”的复合索引，并且，这个操作模式往往是潜在死锁和性能波动的温床。

EXPLAIN 中看到 Using merge 说明什么

当你在SQL语句的EXPLAIN输出结果里，Extra列出现了诸如Using merge，或者更具体的Using sort_union(idx_a,idx_b)、Using intersect(uk_accept_id,idx_status)时，事情就变得有趣了。这直接宣告了MySQL优化器当前的策略：它没有找到或选择那个“一劳永逸”的完美索引，而是启动了索引合并（index merge）策略来组合多个索引的扫描结果。

• 什么情况下容易触发？ 最常见的诱因有两个：一是WHERE条件中包含了多个OR连接（例如WHERE a = 1 OR b = 2）；二是条件用AND连接了多个列，但这些列并非某个现有复合索引的前缀列（例如有status和accept_id的单列索引，查询WHERE status = 'done' AND accept_id = 123，却缺少(status, accept_id)这样的复合索引）。
• 默认开启但成本估算未必准。从MySQL 5.6版本开始，index_merge优化默认是开启的。然而，它的成本估算模型在高并发、频繁更新的场景下，很容易出现偏差，导致优化器做出看似合理实则低效的选择。
• 别被“用了多个索引”迷惑。这不等同于高效。实际上，引擎需要分别扫描多个索引，然后在内存中进行归并排序或求交集/并集，其带来的额外I/O和CPU开销，有时反而比全表扫描或使用一个不那么完美的单索引还要高。

Using merge 为什么容易导致死锁

这才是问题的关键所在，也是许多线上故障的根源。索引合并策略会显著增加死锁发生的概率。原理其实不难理解：当两个并发事务，各自通过index merge以不同的顺序访问并锁定同一组索引时（例如，事务A先锁定uk_accept_id索引上的记录，再请求idx_status上的锁；而事务B的执行顺序恰好相反），就非常容易形成循环等待，即死锁。

• 典型场景再现：一条UPDATE语句，其WHERE条件同时命中了uk_accept_id和idx_status两个索引，触发index merge。当两个这样的会话并发执行时，死锁警报很可能就此拉响。
• 死锁日志里的线索：在MySQL的死锁日志中，你常会看到类似这样的描述：*** (1) WAITING FOR THIS LOCK TO BE GRANTED: ... index uk_accept_id ... *** (2) HOLDS THE LOCK(S): ... index idx_status ...，清晰展示了锁资源的循环等待关系。
• 存储引擎的差异：需要明确的是，MyISAM引擎由于使用表级锁，不存在死锁问题。但在使用行级锁的InnoDB引擎下，index merge无疑是死锁的高发区之一，必须谨慎对待。

怎么关掉或绕过 Using merge

看到Using merge，直接全局关闭index_merge优化（SET optimizer_switch='index_merge=off'）是一种简单粗暴的做法，但并不推荐，因为它可能误伤那些真正受益于此优化的少数查询。更稳妥的做法是进行针对性的干预和优化：

• 治本之策：创建合适的复合索引。这是最根本的解决方案。分析查询模式，为经常同时出现在WHERE条件中的列创建复合索引。例如，对于WHERE status = ? AND accept_id = ?这样的查询，直接创建一个INDEX idx_status_accept (status, accept_id)的复合索引，优化器通常就会放弃index merge，转而使用这个更高效的索引。
• 强制引导：使用FORCE INDEX。如果暂时无法修改索引结构，可以在特定查询中使用FORCE INDEX提示，强制优化器使用你认为更优的索引（比如主键或一个高选择性的覆盖索引），例如：SELECT * FROM t FORCE INDEX (PRIMARY) WHERE ...。
• 查询改写：拆分OR条件。对于由OR条件引发的index merge，可以尝试将查询改写为多个使用UNION ALL连接的子查询（需确保子查询结果集不重叠）。这样，每个子查询可能都能高效地使用一个索引，从而让优化器放弃合并策略。
• 借助执行计划细节做判断。多关注EXPLAIN输出中的rows和filtered列。如果rows预估扫描的行数很大，但filtered（表示存储引擎返回的数据在服务层过滤后剩余的比例）却极低，那就明确说明这次index merge的实际过滤效果很差，优化价值低，应该优先优化查询条件或索引。

merge 引擎表和 Using merge 完全无关

最后，必须澄清一个常见的概念混淆。MySQL中确实存在一种名为MERGE的存储引擎（MRG_MyISAM），它主要用于将多个结构相同的MyISAM表聚合成一个逻辑表进行查询。但这与执行计划中间出现的Using merge提示完全没有关系。前者是物理表的组织方式，属于DDL层面；后者是单条SQL执行时优化器选择的索引访问策略，属于执行计划层面。将两者混为一谈，会让性能排查工作走入完全错误的方向。

说到底，在进行SQL性能分析时，你的目光应该始终聚焦在EXPLAIN输出的几个关键列上：type（访问类型）、key（实际使用的索引）以及Extra（额外信息）。尤其是当Extra列出现任何以Using开头的提示时，都值得你停下来，仔细琢磨一下背后的含义。Using merge就是其中最需要警惕的信号之一。