本文探讨了MySQL中遇到'TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION'错误的原因，指出当等待列表中的事务超过200或检查的锁超过1,000,000时，MySQL将视为死锁并回滚事务。在InnoDB源代码中，定义了LOCK_MAX_N_STEPS_IN_DEADLOCK_CHECK和LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK限制来判断死锁。通过递归函数lock_deadlock_recursive()检查死锁，当递归深度或成本超过预设值时，判定为死锁。"
54587528,3061765,JavaWeb响应与请求详解：HttpServletResponse与HttpServletRequest,"['JavaWeb', 'HTTP响应', 'HTTP请求', '响应头', '请求头', '字符编码']
最近碰到“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
最低0.47元/天 解锁文章
273
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
