很早之前我写过几篇关于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，也会触发死锁。有的时候我们可以正面来图例，或者通过死锁日志来推理。给我的一个启发是太极。
放在锁的角度来理解就会好很多。
用一张不太形象的图表示就是，左边的部分是insert操作在会话1中，右边的是在会话2和会话3中，都持有S锁，然后会因为同样的原因事务回滚后，他们的S锁会升级为X锁导致死锁发生。
按照这个思路，我们可以继续扩展出几个场景。比如delete的方式。
按照这样的思路，可以构建出很多的死锁场景来。