您好,登錄后才能下訂單哦!
本篇內容主要講解“mysql innodb_deadlock_detect檢測和處理方法是什么”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“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檢測和處理方法是什么”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。