一 前言
死锁，其实是一个很有意思也很有挑战的技术问题，大概每个DBA和部分开发同学都会在工作过程中遇见 。关于死锁我会持续写一个系列的案例分析，希望能够对想了解死锁的朋友有所帮助。
二 案例分析
2.1 业务场景
业务开发同学要初始化数据，他们的逻辑是批量执行insert values(x,x,x),(x,x,x); 该表有唯一键，批量插入的唯一键相邻，出现大量死锁。
2.2 环境说明
MySQL 5.6.24 事务隔离级别为RR
CREATE TABLE tc (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT ‘自增ID’,
c1 bigint(20) unsigned NOT NULL DEFAULT ‘0’,
c2 bigint(20) unsigned NOT NULL DEFAULT ‘0’,
c3 bigint(20) unsigned NOT NULL DEFAULT ‘0’,
c4 tinyint(4) NOT NULL DEFAULT ‘0’,
c5 tinyint(4) NOT NULL DEFAULT ‘0’,
created_at datetime NOT NULL DEFAULT ‘1970-01-01 08:00:00’,
deleted_at datetime NOT NULL DEFAULT ‘1970-01-01 08:00:00’,
PRIMARY KEY (id),
UNIQUE KEY uniq_cid_bid_dt_tid (c1,c2,deleted_at,c3)
) ENGINE=InnoDB AUTO_INCREMENT=19 DEFAULT CHARSET=utf8mb4
2.3 测试用例
2.4 死锁日志
2018-04-01 21:41:34 0x7f75c8bff700
*** (1) TRANSACTION:
TRANSACTION 2004, ACTIVE 6 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 2
MySQL thread id 517219, OS thread handle 40, query id 79 127.0.0.1 root update
INSERT IGNORE INTO tc (c2, c1, c3, created_at, c4, c5) VALUES
(95529, 4083702165, 3549685, now(), 1, 4),
(95529, 4083702165, 3549694, now(), 1, 4)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 29 page no 4 n bits 72 index uniq_cid_bid_dt_tid of table test.tc trx id 2004 lock mode S waiting
*** (2) TRANSACTION:
TRANSACTION 1999, ACTIVE 16 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 4
MySQL thread id 517587, OS thread handle 92, query id 84 127.0.0.1 root update
INSERT IGNORE INTO tc (c2, c1, c3, created_at, c4, c5) VALUES
(95529, 4083702165, 3549691, now(), 1, 5)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 29 page no 4 n bits 72 index uniq_cid_bid_dt_tid of table test.tc trx id 1999 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 29 page no 4 n bits 72 index uniq_cid_bid_dt_tid of table test.tc trx id 1999 lock_mode X locks gap before rec insert intention waiting
*** WE ROLL BACK TRANSACTION (1)
2.5 分析死锁日志
首先我们要再次强调insert 插入操作的加锁逻辑。
第一阶段: 唯一性约束检查，先申请LOCK_S + LOCK_ORDINARY
第二阶段: 获取阶段一的锁并且insert成功之后,插入的位置有Gap锁:LOCK_INSERT_INTENTION,为了防止其他insert唯一键冲突。
新数据插入完成之后:LOCK_X + LOCK_REC_NOT_GAP
对于insert操作来说，若发生唯一约束冲突，需要对冲突的唯一索引申请加上S Next-key Lock。如果其他会话中包含已经插入记录的事务没有提交，则申请加锁出现等待，show engine innodb status中的事务列表中会提示 lock mode S waiting 。
从这里会发现，即使是RC事务隔离级别，也同样会存在Next-Key Lock锁，从而阻塞并发。然而，文档没有说明的是，对于检测到冲突的唯一索引，等待线程在获得S Lock之后，还需要对下一个记录进行加锁，在源码中由函数row_ins_scan_sec_index_for_duplicate进行判断.
其次 我们需要了解锁的兼容性矩阵。
从兼容性矩阵我们可以得到如下结论:
INSERT操作之间不会有冲突。
GAP,Next-Key会阻止Insert。
GAP和Record,Next-Key不会冲突
Record和Record、Next-Key之间相互冲突。
已有的Insert锁不阻止任何准备加的锁。
已经持有的gap 锁会阻塞插入意向锁INSERT_INTENTION
另外 对于通过唯一索引更新或者删除不存在的记录，会申请加上 gap锁。
了解上面的基础知识，我们开始对死锁日志进行分析:
T1: sess2 执行批量insert 4条记录，先插入的记录构成唯一键(95529, 4083702165,now(),3549694),该记录在插入完成之后获取到的锁:LOCK_X + LOCK_REC_NOT_GAP。
T2: sess1 insert两条记录 (95529, 4083702165, 3549694, now(), 1, 4),和sess2中的唯一键冲突，于是申请S Next-key Lock,但是和sess2 的LOCK_REC_NOT_GAP 冲突(共享锁和已经持有的排他锁冲突),系统提示RECORD LOCKS space id 29 page no 4 n bits 72 index uniqcidbiddttid of table test.tc trx id 2004 lock mode S waiting
T3: sess2 insert 记录(95529, 4083702165, 3549691, now(), 1, 5),会申请锁LOCK_INSERT_INTENTION，其中3549691与sess1 中的3549694相邻,sess1申请S Next-key Lock会阻塞记录3549691插入。
T1时刻sess2(持有LOCK_REC_NOT_GAP)，T2时刻 sess1(申请S Next-key Lock）被sess2 阻塞，T3时刻sess2(插入意向锁等待sess1的gap锁释放) 构成循环等待，进而导致死锁。
注意,这里对insert 唯一键的加锁逻辑自己可能表述不准确，望读者朋友多讨论。
2.6 解决方法
其实针对此类并发insert导致的死锁，并没有好的解决方法，至少在sql层面没有行之有效的方法。之前的还可以调整sql的执行顺序，简化业务sql逻辑。但是对于此类情况 只能调整唯一索引，或者尽量将初始化的数据打散，调整唯一索引要调整整体的业务层面的逻辑了，需要开发深度介入。
三 小结
本案例的死锁要素是 1 并发insert 2 并发插入的记录唯一键相邻，GAP,Next-Key会阻止Insert。
