標籤:output ase innodb dead actions htm details 遞迴 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
MySQL死結檢測和復原