一次 MySQL 线上死锁分析实战

关键词：MySQL Index Merge

前言

MySQL 的锁机制相信大家在学习 MySQL 的时候都有简单的了解过，那既然有锁就必定绕不开死锁这个问题。其实 MySQL 在大部分场景下是不会存在死锁问题的（比如并发量不高，SQL 写得不至于太拉胯的情况），但是在高并发的业务场景下，一不注意就会产生死锁，而这个死锁分析起来也比较麻烦。

前段时间在公司实习的时候就遇到了一个比较奇怪的死锁，之前一直没来得及好好整理，最近有空复现了一下，算是积累一点经验。

业务场景

简单说一下业务背景，公司做的是电商直播，我负责的是主播端相关的业务。而这个死锁就出现在主播后台对商品信息进行更新的时候。

我们的一个商品会有两个关联的 ID，通过其中任何一个 ID 都无法确定唯一一件商品（也就是说这个 ID 和商品是一对多的关系），只能同时查询两个 ID，才能确定一件商品。所以在更新商品信息的时候，需要在 where 条件中同时指定两个 ID，下面是死锁 SQL 的结构（已脱敏）：

UPDATE test_table SET `name`="zhangsan" WHERE class_id = 10 AND teacher_id = 8;

这个 SQL 非常简单，根据两个等值条件，对一个字段进行更新。

不知道你看到这个 SQL 会不会懵逼，按常理来说，应该是一个事务里有多条 SQL 才会有可能出现死锁，这一条 SQL 怎么可能出现死锁呢？

是的，我当时也有这样的疑惑，甚至怀疑是不是报警系统瞎报（最后证明不是…），当时是真的摸不着头脑。并且因为数据库权限的原因，想看死锁日志都看不到，又是临近下班的时候，找 DBA 能麻烦死，所以就直接搜索引擎走起了……（关键词：update 死锁 单条 sql），最后查出来是由于 MySQL 的索引合并优化导致的，即 Index Merge，下面会进行详细讲解并复现一下死锁场景。

索引合并

Index Merge 是 MySQL 在 5.0 的时候引入的一项优化功能，主要是用于优化一条 SQL 使用多个索引的情况。

我们来看刚刚的 SQL，假设 class_id 和 teacher_i