mysql innodb_deadlock_detect檢測和處理

innodb_deadlock_detect是MySQL的一個系統變數。


版本： 5.7.15
命令列格式：–innodb-deadlock-detect
影響範圍：Global
引數型別：boolean
預設值：ON
作用：該選項使用了禁用MySQL的死鎖檢測功能的。在高併發系統上，當許多執行緒等待同一個鎖時，死鎖檢測可能導致速度減慢。 有時，當發生死鎖時，如果禁用了死鎖檢測則可能會更有效，這樣可以依賴innodb_lock_wait_timeout的設定進行事務回滾。


MySQL預設情況下是開啟了死鎖檢測的，InnoDB自動檢測傳送死鎖的事務，並回滾其中的一個事務或所有導致死鎖的事務。InnoDB會在導致死鎖的十五中選擇一個權重比較小的事務來回滾，這個權重值可能是由該事務insert, updated, deleted的行數決定的。


如果innodb_table_locks = 1(預設值)並且autocommit = 0，則InnoDB能感知到表鎖的存在，並且上層的MySQL層知道行級鎖。 否則，InnoDB無法檢測到由MySQL LOCK TABLES語句設定的表鎖或由除InnoDB之外的儲存引擎設定的鎖定的死鎖。 透過設定innodb_lock_wait_timeout系統變數的值來解決這些情況。


當InnoDB執行事務的完全回滾時，將釋放由事務設定的所有鎖。 但是，如果單個SQL語句由於錯誤而回滾，則語句設定的某些鎖可能會被保留。 這是因為InnoDB以一種格式儲存行鎖，以致之後不能知道哪個鎖由哪個語句設定。


如果SELECT呼叫事務中儲存的函式，並且函式中的語句失敗，則該語句將回滾。 此外，如果在此之後執行ROLLBACK，整個事務將回滾。


如果InnoDB監控器輸出的最近死鎖檢測部分包含一條訊息，指出TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION，這表示處於等待的事務列表長度已達到限制200。超過200個事務的等待列表被視為死鎖，並且將回滾嘗試檢查等待列表的事務。 如果鎖定執行緒必須檢視等待列表上的事務擁有的超過1,000,000個鎖，則也可能發生相同的錯誤。


禁用死鎖檢測
可以透過選項:innodb_deadlock_detect來關閉死鎖檢測。