MySQL死鎖檢測和回滾

最近碰到“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