mysql死鎖的原因和解決方法是什么

這篇文章主要講解了“死鎖的原因和解決方法是什么”，文中的講解內容簡(jiǎn)單清晰，易于學(xué)習與理解，下面請大家跟著(zhù)小編的思路慢慢深入，一起來(lái)研究和學(xué)習“mysql死鎖的原因和解決方法是什么”吧！

當多個(gè)事務(wù)同時(shí)持有和請求同一資源上的鎖而產(chǎn)生循環(huán)依賴(lài)的時(shí)候就產(chǎn)生了死鎖，解決方法為：1、用更低的隔離級別；2、以固定的順序訪(fǎng)問(wèn)你的表和行；3、添加精心選定的索引到表中；4、使用更少的鎖定。

本教程操作環(huán)境：windows7系統、mysql8版本、Dell G3電腦。

當多個(gè)事務(wù)同時(shí)持有和請求同一資源上的鎖而產(chǎn)生循環(huán)依賴(lài)的時(shí)候就產(chǎn)生了死鎖。死鎖發(fā)生在事務(wù)試圖以不同的順序鎖定資源。以StockPrice表上的兩個(gè)事務(wù)為例：

事務(wù)1

START TRANSACTION;
UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = '2002-05-01';
UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = '2002-05-02';
COMMIT;

事務(wù) #2

START TRANSACTION;
UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date = '2002-05-02';
UPDATE StockPrice SET;
COMMIT;

如果不走運的話(huà)，每個(gè)事務(wù)都可以執行完第一個(gè)語(yǔ)句，并在過(guò)程中鎖住資源。然后每個(gè)事務(wù)都試圖去執行第二行語(yǔ)句，當時(shí)卻發(fā)現它被鎖住了。兩個(gè)事務(wù)將永遠的等待對方完成，除非有其他原因打斷死鎖。

為了解決這個(gè)問(wèn)題，數據庫實(shí)現了各種死鎖探查和超時(shí)機制。像InnoDB這樣復雜的存儲引擎會(huì )提示循環(huán)依賴(lài)并且立即返回錯誤。否則死鎖將會(huì )導致查詢(xún)非常緩慢。其他一些不好的做法是等待超時(shí)后放棄。當前InnoDB處理死鎖的方式是回滾持有最少排他行級鎖的事務(wù)。（幾乎最簡(jiǎn)單的回滾的參考指標）

鎖的行為是順序是存儲引擎決定的。因此，一些存儲引擎可能會(huì )在特定的操作順序下發(fā)生死鎖，其他的可能沒(méi)有。死鎖有兩種：一些是因為實(shí)際數據沖突而無(wú)法避免，一些是因為存儲引擎的工作方式產(chǎn)生。

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

如何處理死鎖
死鎖是事務(wù)型數據庫典型的問(wèn)題，但是除非它們頻繁出現以至于你更本不能運行某個(gè)事務(wù)，它們一般是不危險的。正常地，你必須編寫(xiě)你的應用程序使得它們總是準備如果因為死鎖而回滾一個(gè)事務(wù)就重新發(fā)出一個(gè)事務(wù)。

InnoDB使用自動(dòng)行級鎖定。即使在只插入或刪除單個(gè)行的事務(wù)的情況下，你可以遇到死鎖。這是因為這些操作不是真正的“極小的”，它們自動(dòng)對插入或刪除的行的（可能是數個(gè)）索引記錄設置鎖定。

你可以用下列技術(shù)對付死鎖減少它們發(fā)生的可能性：

用Use SHOW INNODB STATUS來(lái)確定最后一個(gè)死鎖的原因。這樣可以幫助你調節應用程序來(lái)避免死鎖。

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

經(jīng)常提交你的事務(wù)。小事務(wù)更少地傾向于沖突。

如果你正使用鎖定讀，（SELECT ... FOR UPDATE或 ... LOCK IN SHARE MODE），試著(zhù)用更低的隔離級別，比如READ COMMITTED。

以固定的順序訪(fǎng)問(wèn)你的表和行。則事務(wù)形成良好定義的查詢(xún)并且沒(méi)有死鎖。

添加精心選定的索引到你的表。則你的查詢(xún)需要掃描更少的索引記錄并且因此設置更少的鎖定。使用EXPLAIN SELECT來(lái)確定對于你的查詢(xún),MySQL認為哪個(gè)索引是最適當的。

使用更少的鎖定。如果你可以接受允許一個(gè)SELECT從一個(gè)舊的快照返回數據，不要給它添加FOR UPDATE或LOCK IN SHARE MODE子句。這里使用READ COMMITTED隔離級別是比較好的，因為每個(gè)在同一事務(wù)里的持續讀從它自己新鮮的快照里讀取。

如果沒(méi)有別的有幫助的了，用表級鎖定系列化你的事務(wù)。用LOCK TABLES對事務(wù)型表（如InnoDB)的正確方法是設置AUTOCOMMIT = 0 并且不調用UNLOCK TABLES直到你明確地提交了事務(wù)。例如，如果你需要寫(xiě)表t1并從表t讀，你可以按如下做：

SET AUTOCOMMIT=0;

LOCK TABLES t1 WRITE, t2 READ, ...;

[do something with tables t1 and t2 here];

COMMIT;

UNLOCK TABLES;

表級鎖定使得你的事務(wù)很好地排隊，并且死鎖被避免了。

領(lǐng)一個(gè)系列化事務(wù)的方法是創(chuàng )建一個(gè)輔助的“semaphore” 表，它只包含一個(gè)單行。讓每個(gè)事務(wù)在訪(fǎng)問(wèn)其它表之前更新那個(gè)行。以這種方式，所有事務(wù)以序列的方式發(fā)生。注意，InnoDB即時(shí)死鎖檢測算法也能在這種情況下起租用，因為系列化鎖定是行級鎖定。超時(shí)方法，用MySQL表級鎖定，必須被用來(lái)解決死鎖。

在應用程序中使用LOCK TABLES命令，如果AUTOCOMMIT=1,MySQL不設定InnoDB表鎖定。