一个mysql死锁场景实例解析
发布时间：2022-03-20 18:17:53 所属栏目：MySql教程 来源：互联网
导读：最近遇到一个mysql在RR级别下的死锁问题，感觉有点意思，研究了一下，做个记录。 涉及知识点：共享锁、排他锁、意向锁、间隙锁、插入意向锁、锁等待队列 B执行完4之后还是一切正常 A执行5的时候，被block B接着执行6，B报死锁，B回滚，A插入数据 show engi
|
最近遇到一个mysql在RR级别下的死锁问题，感觉有点意思，研究了一下，做个记录。 涉及知识点：共享锁、排他锁、意向锁、间隙锁、插入意向锁、锁等待队列 B执行完4之后还是一切正常 A执行5的时候，被block B接着执行6，B报死锁，B回滚，A插入数据 show engine innodb status中可以看到死锁信息，这里先不贴，先解释几种锁的概念，再来理解死锁过程 共享(S)锁/互斥(X)锁 共享锁允许事务读取记录 互斥锁允许事务读写记录 这两种其实是锁的模式可以和行锁、间隙锁混搭，多个事务可以同时持有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')之前的间隙锁，却也在等待那个插入意向锁。这说的什么玩意儿，是不是很诡异？ 从头开始分析过程 A、B分别begin，开始事务 A先执行select * from t where a=0 and b='0' for update; ，先加了IX锁，然后原本意图为给(0, '0')这条记录加排他行锁，但是记录不存在，所以变成了排他间隙锁(-∞,1) B再执行select * from t where a=0 and b='0' for update; ，也是先加了IX锁，因为记录不存在，所以加上了排他间隙锁(-∞,1)，但是由于间隙锁相互兼容，所以没有block A执行insert into t(a,b) values(0,'0'); ，这时候，要开始真正insert了，A需要获得(0,'0')上的插入意向锁，由于和B持有的(-∞,1)排他间隙锁冲突，所以锁等待，进入记录(0,'0')的锁等待队列（虽然记录并不存在） B执行insert into t(a,b) values(0,'0'); ，要获取插入意向锁，发现虽然B自己是持有(-∞,1)的排他间隙锁，但是A也有，所以进入等待队列，等待A释放 叮，死锁发生 死锁信息解读 事务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。 （编辑：我爱故事小小网_铜陵站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330570号