mysql InnoDB在什么情况下会产生死锁的现象
这片文章,可能会需要大家对InnoDB的数据结构和隔离级别有一定的了解。
我之前整理的有这部分的文章:
通过B+Tree平衡多叉树理解InnoDB引擎的聚集和非聚集索引
InnoDB的隔离级别是如何实现的
文章前提:InnoDB RR隔离级别。
什么是死锁
mysql死锁是多个事务因竞争锁而造成的一种相互等待的僵局。
我之前有一篇介绍Java线程死锁的文章:Java线程死锁-DeadLock,
与mysql中的死锁比较相似,线程就相当于mysql中的事务,资源就是mysql的锁。
会出现死锁的几种情况
我们有两张结构一模一样的表,分别为t1和t2:
id:integer | token:varchar | message:varchar |
---|
其中id是主键(自增),token是非聚集索引,message没有索引。
1、一张表两行记录交叉申请互斥锁
A执行到第二步时,等待B释放第一步的锁,而B需要执行完第二步结束事务之后才能释放锁;
B执行到第二步时,等待A释放第一步的速,这样A和B都无法进行下去,就产生了死锁现象。
2、两张表两行记录交叉申请互斥锁
这种情况与1中的类似。
3、聚集索引与非聚集索引冲突
这种不一定会产生死锁,表面上也看不出来。
假设A中满足条件的记录加锁顺序为(5,4,3,2,1),B中加锁顺序为(1,2,3,4,5),这里的排序是对应record的主键;
(InnoDB的锁是逐步获取的,而不是一次获取全部需要的锁。)
有可能A加锁了5和4,B加锁了1、2、3,再往下进行的话就会出相互等待陷入僵局的情况,就是死锁。
4、聚集索引冲突
这种情况与3中的类似。
5、间隙锁冲突
这种情况是因为A第一步使用了间隙锁,在A释放锁之前B第二步无法完成,也会形成死锁。
innodb提供了wait-for graph算法来主动进行死锁检测,每当加锁请求无法立即满足需要并进入等待时,wait-for graph算法都会被触发,检测是否出现等待环路。当检测到死锁时,InnoDB会选择代价比较小的事务进行回滚。
以上见解如有不当之处,请予指正。
参考文章:
zhanlijun:mysql死锁问题分析
脚本之家某作者:MySQL Innodb表导致死锁日志情况分析与归纳
程序员历小冰:MySQL死锁系列-常见加锁场景分析