詳解MySQL中的死鎖情況以及對死鎖的處理方法

當多個事務同時持有和請求同一資源上的鎖而產生迴圈依賴的時候就產生了死鎖。死鎖發生在事務試圖以不同的順序鎖定資源。以stockprice表上的兩個事務為例：

事務1start transaction;

update stockprice set close = 45.50 where stock_id = 4 and date = '2';

update stockprice set close = 19.80 where stock_id = 3 and date = '2002-05-02';

commit;

事務 #2

start transaction;

update stockprice set high = 20.12 where stock_id = 3 and date = '2002-05-02';

update stockprice set;

commit;

如果不走運的話，每個事務都可以執行完第乙個語句，並在過程中鎖住資源。然後每個事務都試圖去執行第二行語句，當時卻發現它被鎖住了。兩個事務將永遠的等待對方完成，除非有其他原因打斷死鎖。

為了解決這個問題，資料庫實現了各種死鎖探查和超時機制。像innodb這樣複雜的儲存引擎會提示迴圈依賴並且立即返回錯誤。否則死鎖將會導致查詢非常緩慢。其他一些不好的做法是等待超時後放棄。當前innodb處理死鎖的方式是回滾持有最少排他行級鎖的事務。（幾乎最簡單的回滾的參考指標）

鎖的行為是順序是儲存引擎決定的。因此，一些儲存引擎可能會在特定的操作順序下發生死鎖，其他的可能沒有。死鎖有兩種：一些是因為實際資料衝突而無法避免，一些是因為儲存引擎的工作方式產生。

只有部分或者完全回滾其中的乙個事務才可能打破死鎖。死鎖是事務系統中客觀存在的事實，你的應該在設計上必須應該考慮處理死鎖。一些業務系統可以從頭重試事務。

如何處理死鎖

死鎖是事務型資料庫典型的問題，但是除非它們頻繁出現以至於你更本不能執行某個事務，它們一般是不危險的。正常地，你必須編寫你的應用程式使得它們總是準備如果因為死鎖而回滾乙個事務就重新發出乙個事務。

innodb使用自動行級鎖定。即使在只插入或刪除單個行的事務的情況下，你可以遇到死鎖。這是因為這些操作不是真正的「極小的」，它們自動對插入或刪除的行的（可能是數個）索引記錄設定鎖定。

你可以用下列技術程式設計客棧對付死鎖減少它們發生的可能性：

用use show innodb status來確定最後乙個死鎖的原因。這樣可以幫助你調節應用程式來避免死鎖。

總是準備著重新發出事務，如果它因為死鎖而失敗了。死鎖不危險，再試一次。

經常提交你的事務。小事務更少地傾向於衝突。

如果你正使用鎖定讀，（select ... for update或 ... lock in share mode），試著用更低的隔離級別，比如read committed。

以固定的順序訪問你的表和行。則事務形成良好定義的查詢並且沒有死鎖。

新增精心選定的索引到你的表。則你的查詢需要掃瞄更少的索引記錄並且因此設定更少的鎖定。使用explain select來確定對於你的查詢,mysql認為哪個索引是最適當的。

使用更少的鎖定。如果你可以接受允許乙個select從乙個舊的快照返回資料，不要給它新增for update或lock in share mode子句。這裡使用read committed隔離級別是比較好的，因為每個在同一事務裡的持續讀從它自己新鮮的快照裡讀取。

如果沒有別的有幫助的了，用表級鎖定系列化你的事務。用lock tables對事務型表（如innodb)的正確方法是設定autocommit = 0 並且不呼叫unlock tables直到你明確地提交了事務。例如，如果你需要寫表t1並從表t讀，你可以按如下做：

set autocommit=0;

lock tables t1 write, t2 read, ...;

[do something withmyrfby tables t1 and t2 here];

commit;

unlock t

表級鎖定使得你的事務很好地排隊，並且死鎖被避免了。

領乙個系列化事務的方法是建立乙個輔助的「semaphore」表，它只包含乙個單行。讓每個事務在訪問其它表之前更新那個行。以這種方式，所有事務以序列的方式發生。注意，innodb即時死鎖檢測演算法也能在這種情況下起租用，因為系列化鎖定是行級鎖定。超時方法，用mysql表級鎖定，必須被用來解決死鎖。

在應用程式中使用lock tables命令程式設計客棧，如果autocommit=1,mysql不設定innodb表鎖定。

本文標題: 詳解mysql中的死鎖情況以及對死鎖的處理方法

本文位址: