一个mysql死锁场景分析

最近遇到一个mysql在RR级别下的死锁问题，感受有点意思，研究了一下，作个记录。
涉及知识点：共享锁、排他锁、意向锁、间隙锁、插入意向锁、锁等待队列

有帮助的话就点个赞，关注专栏数据库，不跑路吧～～
不按期更新数据库的小知识和实用经验，让你不用再须要担忧跑路

---

场景

隔离级别：Repeatable-Read
表结构以下

create table t (
    id int not null primary key AUTO_INCREMENT,
    a int not null default 0,
    b varchar(10) not null default '',
    c varchar(10) not null default '',
    unique key uniq_a_b(a,b),
    unique key uniq_c(c)
);

初始化数据

insert into t(a,b,c) values(1,'1','1');

有A/B两个session，按以下顺序执行两个事务

结果是

• B执行完4以后仍是一切正常
• A执行5的时候，被block
• B接着执行6，B报死锁，B回滚，A插入数据

show engine innodb status中能够看到死锁信息，这里先不贴，先解释几种锁的概念，再来理解死锁过程

共享(S)锁/互斥(X)锁

• 共享锁容许事务读取记录
• 互斥锁容许事务读写记录

这两种实际上是锁的模式能够和行锁、间隙锁混搭，多个事务能够同时持有S锁，可是只有一个事务能持有X锁

意向锁

一种表锁(也是一种锁模式)，代表有事务即将给对应表的记录加S或者X锁。SELECT ... LOCK IN SHARE MODE会在给记录加S锁以前先给表加IS锁，SELECT ... FOR UPDATE会在给记录加X锁以前给表加IX锁。
这是一种mysql的锁优化策略，并非很清楚意向锁的优化点在哪里，求大佬指教

两种锁的兼容状况以下

行锁

很简单，给对应行加锁。好比update、select for update、delete等都会给涉及到的行加上行锁，防止其余事务的操做

间隙锁

在RR隔离级别下，为了防止幻读现象，除了给记录自己，还须要为记录两边的间隙加上间隙锁。
好比列a上有一个普通索引，已经有了一、五、10三条记录，select * from t where a=5 for update除了会给5这条记录加行锁，还会给间隙(1,5)和(5,10)加上间隙锁，防止其余事务插入值为5的数据形成幻读。
当a上的普通索引变成惟一索引时，不须要间隙锁，由于值惟一，select * from t where a=5 for update不可能读出两条记录来。

间隙锁相互兼容，由于若是互斥，事务A持有左半段(1,5)，事务B持有右半段(1,10)，那么当前面那个例子中a=5的记录被删除时，理论上左右两个间隙锁得合并成一个新锁(1,10)，那么这个新的大范围锁属于谁呢？因此间隙锁相互兼容，不论是S间隙锁仍是X间隙锁

插入意向锁

插入意向锁实际上是一种特殊的间隙锁，从前面对间隙锁的描述中能够得知，两个事务在真正insert以前能够同时持有一段间隙的间隙锁，锁不住真正insert的这个动做。真正insert以前，mysql还会尝试获取对应记录的插入意向锁，代表有在间隙中插入一个值的意向。
插入意向锁和间隙锁互斥，好比事务1锁了(1,5)这个间隙，事务2就不能获取到a=3的插入意向锁，因此须要锁等待。

死锁过程分析

接下来就能够来分析前面那个例子中的死锁过程了，先看show engine innodb status

*** (1) TRANSACTION:
TRANSACTION 5967, ACTIVE 8 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 9, OS thread handle 140528848688896, query id 537 192.168.128.1 root update
insert into t(a,b) values(0,'0')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 64 page no 4 n bits 72 index uniq_a_b of table `t2`.`t` trx id 5967 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 5968, ACTIVE 7 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 8, OS thread handle 140528848484096, query id 538 192.168.128.1 root update
insert into t(a,b) values(0,'0')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 64 page no 4 n bits 72 index uniq_a_b of table `t2`.`t` trx id 5968 lock_mode X locks gap before rec
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 64 page no 4 n bits 72 index uniq_a_b of table `t2`.`t` trx id 5968 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

*** WE ROLL BACK TRANSACTION (2)

session A(即TRANSACTION 5967)正在等待记录(a=1,b='1')以前的插入意向锁，session B(即TRANSACTION 5968)持有记录(a=1,b='1')以前的间隙锁，却也在等待那个插入意向锁。这说的什么玩意儿，是否是很诡异？

从头开始分析过程

1. A、B分别begin，开始事务
2. A先执行select * from t where a=0 and b='0' for update;，先加了IX锁，而后本来意图为给(0, '0')这条记录加排他行锁，可是记录不存在，因此变成了排他间隙锁(-∞,1)
3. B再执行select * from t where a=0 and b='0' for update;，也是先加了IX锁，由于记录不存在，因此加上了排他间隙锁(-∞,1)，可是因为间隙锁相互兼容，因此没有block
4. A执行insert into t(a,b) values(0,'0');，这时候，要开始真正insert了，A须要得到(0,'0')上的插入意向锁，因为和B持有的(-∞,1)排他间隙锁冲突，因此锁等待，进入记录(0,'0')的锁等待队列（虽然记录并不存在）
5. B执行insert into t(a,b) values(0,'0');，要获取插入意向锁，发现虽然B本身是持有(-∞,1)的排他间隙锁，可是A也有，因此进入等待队列，等待A释放
6. 叮，死锁发生

死锁信息解读

事务1(TRANSACTION 5967)，等待得到锁index uniq_a_b of table t2.t trx id 5967 lock_mode X locks gap before rec insert intention waiting，即在惟一索引uniq_a_b上的插入意向锁(lock_mode X locks gap before rec insert intention)
锁的边界为

0: len 4; hex 80000001; asc     ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

代表两行记录

• 0和1表示uniq_a_b上的值，a=1，b=0x31（即'1'的ascii码）
• a=1,b='1'对应的主键id=1，由于innodb的索引结构决定的，二级索引(非主键索引)指向主键索引，主键索引再指向数据，因此须要给主键加索引

至于int值按位或上的0x80000000就不是很清楚为何了，须要大佬解读

事务2(TRANSACTION 5968)，持有间隙锁index uniq_a_b of table t2.t trx id 5968 lock_mode X locks gap before rec，等待插入意向锁index uniq_a_b of table t2.t trx id 5968 lock_mode X locks gap before rec insert intention，因此死锁发生。

原则上是innodb引擎判断哪一个事务回滚代价小就回滚哪一个事务，可是具体评判标准不是很清楚（再一次须要大佬），这里innodb选择了回滚事务2。至此，死锁过程分析完毕

One More Thing

还没完。。。有个神奇的现象是，若是表结构变成

create table t (
    id int not null primary key AUTO_INCREMENT,
    a int not null default 0,
    b varchar(10) not null default '',
    c varchar(10) not null default '',
    unique key uniq_c(c),
    unique key uniq_a_b(a,b)
);
insert into t(a,b,c) values(1,1,1);

只是把c上的惟一索引uniq_c放到了uniq_a_b前面，那么最后的死锁信息就变了！

*** (1) TRANSACTION:
TRANSACTION 5801, ACTIVE 5 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 5, OS thread handle 140528848688896, query id 380 192.168.128.1 root update
insert into t2(a,b) values(0,'0')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 5 n bits 72 index uniq_a_b of table `t2`.`t2` trx id 5801 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 5802, ACTIVE 4 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 6, OS thread handle 140528848484096, query id 381 192.168.128.1 root update
insert into t2(a,b) values(0,'0')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 56 page no 5 n bits 72 index uniq_a_b of table `t2`.`t2` trx id 5802 lock_mode X locks gap before rec
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 4 n bits 72 index uniq_c of table `t2`.`t2` trx id 5802 lock mode S waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 0; hex ; asc ;;
 1: len 4; hex 80000002; asc     ;;

*** WE ROLL BACK TRANSACTION (2)

事务2等待的锁由前面的插入意向锁变成了共享锁。什么鬼？
因为没看过源码，只能根据现象倒推：由于表结构上c的惟一索引在(a,b)前面，而插入的时候没指定c的值，用的默认值0，innodb须要先去查一下有没有0这条记录，有的话就要报惟一键冲突了，因此先要加S锁，可是在(0,'0')这条记录上已经有了IX锁，看一下前面的兼容性矩阵，S锁和IX锁互斥，因此也只能锁等待

总结

看似一句简单的select和insert，底下设计很是复杂的锁机制，理解这些锁机制有利于写出高效的SQL(至少是正确的😂)

遗留问题：

1. 意向锁的优化点是哪
2. 锁信息里，行记录按位或上的0x80000000是啥
3. 锁互斥的断定顺序，场景1中，(0,'0')上有兼容的间隙锁，也有等待队列中的锁，先断定哪一个？
4. innodb计算事务回滚代价的算法

有帮助的话就点个赞，关注专栏数据库，不跑路吧～～
不按期更新数据库的小知识和实用经验，让你不用再须要担忧跑路

参考资料

• http://hedengcheng.com/?p=771
• https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-insert-intention-locks
• https://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html
• https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-understanding-innodb-locking.html