推薦學習:
在我們使用鎖的時候,有一個問題是需要注意和避免的,我們知道,排它鎖有互斥的特性。一個事務或者說一個執行緒持有鎖的時候,會阻止其他的執行緒獲取鎖,這個時候會造成阻塞等待,如果迴圈等待,會有可能造成死鎖。
這個問題我們需要從幾個方面來分析,一個是鎖為什麼不釋放,第二個是被阻塞了怎麼辦,第三個死鎖是怎麼發生的,怎麼避免。
回顧:鎖什麼時候釋放?
事務結束(commit,rollback)﹔
使用者端連線斷開。
如果一個事務一直未釋放鎖,其他事務會被阻塞多久?會不會永遠等待下去?
如果是,在並行存取比較高的情況下,如果大量事務因無法立即獲得所需的鎖而掛起,會佔用大量計算機資源,造成嚴重效能問題,甚至拖跨資料庫。
線上怕不怕這個錯?
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
MySQL有一個引數來控制獲取鎖的等待時間,預設是50秒。
show VARIABLES like "innodb_lock_wait_timeout";
對於死鎖,是無論等多久都不能獲取到鎖的,這種情況,也需要等待50秒鐘嗎?那不是白白浪費了50秒鐘的時間嗎?
演示一下,開兩個對談:
方便對時間線的提現,這裡用圖片,有興趣的可以跟著模仿一下
栗子一:
栗子二:
在第一個事務中,檢測到了死鎖,馬上退出了,第二個事務獲得了鎖,不需要等待50秒:
[Err] 1213 - Deadlock found when trying to get lock; try restarting transaction
為什麼可以直接檢測到呢?是因為死鎖的發生需要滿足一定的條件,對於我們程式設計師來說,有明確的條件,意味著能判定,所以在發生死鎖時,InnoDB一般都能通過演演算法(wait-for graph)自動檢測到。
那麼死鎖需要滿足什麼條件?死鎖的產生條件,因為鎖本身是互斥的:
理髮店有兩個總監。一個負責剪頭的Tony老師,一個負責洗頭的Kelvin老師。Tony老師不能同時給兩個人剪頭,這個就叫互斥
。
Tony在給別人在剪頭的時候,你不能讓他停下來幫你剪頭,這個叫不能強行剝奪
。
如果Tony的客戶對Kelvin說:你不幫我洗頭我怎麼剪頭? Kelvin 的客戶對Tony說:你不幫我剪頭我怎麼洗頭?這個就叫形成等待環路
。
實際上,發生死鎖的情況非常多,但是都滿足以上3個條件。
這個也是表鎖是不會發生死鎖的原因,因為表鎖的資源都是一次性獲取的。
如果鎖一直沒有釋放,就有可能造成大量阻塞或者發生死鎖,造成系統吞吐量下降,這時候就要檢視是哪些事務持有了鎖。
首先,SHow STATUS命令中,包括了一些行鎖的資訊:
show status like 'innodb_row_lock_%';
lnnodb_row_lock_current_waits:當前正在等待鎖定的數量;
lnnodb_row_lock_time :從系統啟動到現在鎖定的總時間長度,單位ms;
Innodb_row_lock_time_avg :每次等待所花平均時間;
Innodb_row_lock_time_max:從系統啟動到現在等待最長的一次所花的時間;
lnnodb_row_lock_waits :從系統啟動到現在總共等待的次數。
SHOW命令是一個概要資訊。InnoDB還提供了三張表來分析事務與鎖的情況:
select * from information_schema.INNODB_TRX; --當前執行的所有事務﹐還有具體的語句
select* from information_schema.INNODB_LOCKS; --當前出現的鎖
select * from information_schema.INNODB_LOCK_WAITS; --鎖等待的對應關係
更加詳細的鎖資訊,開啟標準監控和鎖監控:
額外的監控肯定會消耗額外的效能
set GLOBAL innodb_status_output=ON; set GLOBAL innodb_status_output_locks=ON;
通過分析鎖紀錄檔,找出持有鎖的事務之後呢?
如果一個事務長時間持有鎖不釋放,可以kill事務對應的執行緒ID,也就是INNODB_TRX表中的trx_mysql_thread_id,例如執行kill 4,kill 7, kill 8。
當然,死鎖的問題不能每次都靠kill執行緒來解決,這是治標不治本的行為。我們應該儘量在應用端,也就是在編碼的過程中避免。
有哪些可以避免死鎖的方法呢?
推薦學習:
以上就是MySQL死鎖使用詳解及檢測和避免方法的詳細內容,更多請關注TW511.COM其它相關文章!