共計 1217 個字符，預計需要花費 4 分鐘才能閱讀完成。

本篇內容主要講解“mysql innodb_deadlock_detect 檢測和處理方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“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 來關閉死鎖檢測。

到此，相信大家對“mysql innodb_deadlock_detect 檢測和處理方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！