之前也列举了几期的MySQL死锁问题，光有操作演练，还缺少一些自己的分析，所以我就打算补充一下。
首先对于死锁问题，我们分析的背景是基于MySQL事务隔离级别为RR,存储引擎为InnoDB,在MySQL 5.6,5.7版本均可复现问题。
怎么来分析一个死锁问题呢，我一直在琢磨这个问题，自己也总结了不少出现的场景，但是感觉还是有一些欠缺或者不完善的地方。那么我们就换一个思路来分析死锁问题，通过日志来反推死锁产生的可能场景，然后依次深入，扩展，这样一来，这个问题的分析就带有通过很多不确定性分析判断，得到确定性的结果，然后分析和预期一致，这个问题就算基本搞明白了。
所以在此我不给出表结构，只给出死锁的日志来。这样一段日志，是在MySQL设置了死锁检测，输出日志的参数后得到的。
通过一段死锁日志来挖掘一些有价值的信息。
整个死锁的日志分为了两个事务，Transaction 1和Transaction 2，这里需要指出的是，这其实是发生死锁的临界状态的事务信息，就好似一个印章。我们看到的是最后得到的一个状态信息（类似盖上印章的一瞬间），而完整的过程是没法通过日志体现出来的，还有一个，如果仔细看上面的日志就会发现，事务1的日志还是不够完整，持有的锁，等待的锁，只打印出了等待的锁，有很多业内朋友是通过修改内核代码来把这个信息补充完整的。
但是发生死锁的时候是有两个事务互相阻塞，循环形成死锁，我们就依次来分析两个事务的日志信息。
事务1的日志信息如下，我们可以看到整个事务持续（阻塞）了46秒钟，很快就会达到触发超时的阈值，涉及的表有1个（tables in use 1）,有2个锁（一个表级意向锁，一个行锁）语句为： delete from dtest1 where num=10,,加锁的对象是索引num,这个唯一的行锁处于等待状态（WAITING FOR THIS LOCK TO BE GRANTED），相关的锁等待为（lock_mode X waiting，next key锁）。
*** (1) TRANSACTION:
TRANSACTION 2844, ACTIVE 46 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 5, OS thread handle 140582228653824, query id 55 localhost root updating
delete from dtest1 where num=10
2017-09-11T10:07:08.103195Z 6 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 34 page no 4 n bits 72 index num of table `test`.`dtest1` trx id 2844 lock_mode X waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 4; hex 8000000a; asc ;;
1: len 4; hex 8000000a; asc ;;
再来看看第二个事务，内容略长一些。可以看到分为两部分内容，一部分是持有的锁（HOLDS THE LOCK）,锁模式为（lock_mode X locks rec but not gap，no gap lock）,另一部分是等待的锁，锁模式为（lock mode S waiting）
2017-09-11T10:07:08.103243Z 6 [Note] InnoDB: *** (2) TRANSACTION:
TRANSACTION 2843, ACTIVE 92 sec inserting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 2
MySQL thread id 6, OS thread handle 140582228387584, query id 58 localhost root update
insert into dtest1 values(11,10)
2017-09-11T10:07:08.103260Z 6 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 34 page no 4 n bits 72 index num of table `test`.`dtest1` trx id 2843 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 4; hex 8000000a; asc ;;
1: len 4; hex 8000000a; asc ;;
2017-09-11T10:07:08.103301Z 6 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 34 page no 4 n bits 72 index num of table `test`.`dtest1` trx id 2843 lock mode S waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 4; hex 8000000a; asc ;;
1: len 4; hex 8000000a; asc ;;
2017-09-11T10:07:08.103348Z 6 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (1)
大体我们得到了这样的信息，一个事务等待的行锁模式为next key lock,另外一个事务持有record lock,等待的锁为S锁，出现S锁看来是一个突破口，我们就需要明白为什么会是S锁，事务2中相关的SQL是insert语句，如果需要进行唯一性冲突检查的时候，是需要先加一个S锁，所以由此我们可以进一步推理出这个Num对应的索引是一个唯一性索引。
由此我们可以进一步分析，何时得到这个S锁，肯定是在另外一个事务（也可能是其他的事务，比一定是事务1）中会去触发，在事务2中才会持有一个S锁，所以这样一来insert之前是有一个事务在做一个和唯一性索引相关的操作，我们理一下。
事务1相关的SQL：
delete from dtest1 where num=10
事务2相关的SQL:
insert into dtest1 values(11,10)
根据持有的S锁我们可以猜测可能是在事务2之前有一个DML操作阻塞了唯一性索引，我们假设为insert或者delete操作（限定下范围），进一步限定是两个会话中的事务，下面的分析就很重要了。
事务2中的持有的S锁，我们可以从下往上去推理，事务1上面肯定是一个delete操作，也就是日志中的第一部分显示，是一个delete操作。
按照这个方向往下去想，整个死锁的场景应该是下面这样的。
事务2：
insert/delete操作待分析
事务1：
delete from dtest1 where num=10;
事务2：
insert into dtest1 values(11,10);
如果在事务2中先做的是一个insert操作，显然在事务2中会直接抛出duplicate的报错，所以此处在insert,delete中只能是delete的操作，
所以整个死锁的过程真实的情况就是：
事务2：
delete from dtest1 where num=10; --record lock
事务1：
delete from dtest1 where num=10; --申请X锁，进入锁请求队列
事务2：
insert into dtest1 values(11,10); --申请S锁，产生了循环等待。
这个过程也是抛砖引玉，希望大家提出更多的想法。建表语句为：
create table dtest1 (id int primary key,num int unique);
