一个MySQL死锁问题的反思

2018/09/0663 作者：佚名

导读：很早之前我写过几篇关于MySQL死锁的分析，比如但是感觉不过瘾，而且分析的都是一些特定的场景，好像还缺少一些举一反三的感觉，所以今天就补上这一波。 MySQL里的锁兼容列表大体是这样的关系，如果第一次看会有些晕，感觉抓不住重点，其实有

很早之前我写过几篇关于MySQL死锁的分析，比如

但是感觉不过瘾，而且分析的都是一些特定的场景，好像还缺少一些举一反三的感觉，所以今天就补上这一波。

MySQL里的锁兼容列表大体是这样的关系，如果第一次看会有些晕，感觉抓不住重点，其实有一点小技巧。

首先InnoDB实现了两种类似的行锁，即S(共享锁）和X(排他锁），而InnoDB层面的表级意向锁有IS(意向共享锁）和IX9意向排他锁），意向锁之间是互相兼容的，这句话很重要，按照这个思路里面一半的内容就明确了。而另外一部分则是S和X的兼容性。带着S锁和X锁的组合都是互相排斥，只有一类场景例外，那就是都是S锁，是兼容的。所以这个图按照这个思路几乎不用记就能基本理解了。

看起来S锁的组合是很柔和的，从这种场景来看保持兼容，那么出死锁的概率应该很低吧，其实在RR,RC隔离级别下我们可以逐步扩展然后举一反三。

如果S锁的组合在两个会话中是互相兼容，那么接下来的X锁的组合就是互相排斥的。

那么在两个会话并发的场景下，死锁的步骤如下：

mysql> create table dt1 (id int unique

Query OK, 0 rows affected (0.03 sec)

会话1：

begin;

select *from dt1 lock in share mode; --显式共享锁

会话2：

begin;

select *from dt1 lock in share mode; --显式共享锁

会话1：

insert into dt1 values(1); --阻塞

会话2：

insert into dt1 values(2); --触发死锁

所以上面的语句特点很明显，插入的数据分别是1和2，看起来互补冲突也不行。

我们进度稍快一些，我们可能很少看到直接声明share mode的方式，但是有很多时候由其他的场景会触发，其中的一个主要原因就在于对于duplicate数据的检查会开启S锁。这是比较特别的一点，需要注意。

按照这一点来扩展，很容易就可以扩展到3个会话中。

会话1只是负责插入一条数据，会话2,3也紧接着插入一条记录（会话2,3自动提交），但是因为唯一性索引的检查，会导致会话2和会话3都开启了S锁，因为兼容，所以暂时还没影响。如果会话1正常提交，会话2,3的检查会生效，导致数据插入不了，违反唯一性约束，但是我们反其道而行，就可以用一个rollback来释放锁，紧接着会话2和会话3都会获得S锁成功，紧接着获得X锁，细节算法就不说了。这个时候互相阻塞，导致会话3产生死锁，会话2的数据插入依然会成功。

会话1：

begin;

insert into dt1 values(1);

会话2：

insert into dt1 values(1);

会话3：

insert into dt1 values(1);

会话1：

rollback;

看起来很精巧的小测试，但是里面蕴含这大道理，比如按照这个思路，如果后面的两个语句都是delete，也会触发死锁。有的时候我们可以正面来图例，或者通过死锁日志来推理。给我的一个启发是太极。