最近碰到“TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION”。
重新温习下受益良多，其中死锁的判定规则，其实我们早在5年前解决秒杀场景的第一个版本就已经涉及，并且思路很相似，如果有时间的话，我会补充上一批文章说下如果关闭死锁检测对单行更新能提升多少性能。
下面这一段代码展示的是：
“
If the LATEST DETECTED DEADLOCK section of InnoDB Monitor output includes a message stating, “TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION,” this indicates that the number of transactions on the wait-for list has reached a limit of 200. A wait-for list that exceeds 200 transactions is treated as a deadlock and the transaction attempting to check the wait-for list is rolled back. The same error may also occur if the locking thread must look at more than 1,000,000 locks owned by transactions on the wait-for list.
”
在innodb源代码lock/lock0lock.c文件中,定义了两个常量:
/* Restricts the length of search we will do in the waits-for
graph of transactions */
#define LOCK_MAX_N_STEPS_IN_DEADLOCK_CHECK 1000000
/* Restricts the recursion depth of the search we will do in the waits-for
graph of transactions */
#define LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK 200
然后在检查是否产生死锁的函数lock_deadlock_occurs()中有如下代码:
ret = lock_deadlock_recursive(trx, trx, lock, &cost, 0);
switch (ret) {
case LOCK_EXCEED_MAX_DEPTH:
产生死锁
...
break;
}
其中的lock_deadlock_recursive()函数是递归函数,它会检查自身递归深度,其中有如下代码:
ibool too_far
= depth > LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK
|| *cost > LOCK_MAX_N_STEPS_IN_DEADLOCK_CHECK;
...
if (too_far) {
return(LOCK_EXCEED_MAX_DEPTH);
}
因此innodb在检查是否产生死锁时调用lock_deadlock_occurs()检查,这个函数再会调用lock_deadlock_recursive()递归检查锁的数目(不知道这么说是否确切?)，当递归的深度depth大于了一开始介绍的常量LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK,或者cost(不清楚这个代表什么)大于一开始介绍的常量LOCK_MAX_N_STEPS_IN_DEADLOCK_CHECK时,就认为发生了死锁.
资料出处：
http://blog.csdn.net/sunmun/article/details/50088381
https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlock-detection.html
http://www.cnblogs.com/zemliu/p/3502395.html