當(dāng)多個(gè)事務(wù)同時(shí)持有和請(qǐng)求同一資源上的鎖而產(chǎn)生循環(huán)依賴(lài)的時(shí)候就產(chǎn)生了死鎖。死鎖發(fā)生在事務(wù)試圖以不同的順序鎖定資源。以StockPrice表上的兩個(gè)事務(wù)為例:
事務(wù)1
1
2
3
4
|
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
1
2
3
4
|
START TRANSACTION ; UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date = '2002-05-02' ; UPDATE StockPrice SET ; COMMIT ; |
如果不走運(yùn)的話,每個(gè)事務(wù)都可以執(zhí)行完第一個(gè)語(yǔ)句,并在過(guò)程中鎖住資源。然后每個(gè)事務(wù)都試圖去執(zhí)行第二行語(yǔ)句,當(dāng)時(shí)卻發(fā)現(xiàn)它被鎖住了。兩個(gè)事務(wù)將永遠(yuǎn)的等待對(duì)方完成,除非有其他原因打斷死鎖。
為了解決這個(gè)問(wèn)題,數(shù)據(jù)庫(kù)實(shí)現(xiàn)了各種死鎖探查和超時(shí)機(jī)制。像InnoDB這樣復(fù)雜的存儲(chǔ)引擎會(huì)提示循環(huán)依賴(lài)并且立即返回錯(cuò)誤。否則死鎖將會(huì)導(dǎo)致查詢(xún)非常緩慢。其他一些不好的做法是等待超時(shí)后放棄。當(dāng)前InnoDB處理死鎖的方式是回滾持有最少排他行級(jí)鎖的事務(wù)。(幾乎最簡(jiǎn)單的回滾的參考指標(biāo))
鎖的行為是順序是存儲(chǔ)引擎決定的。因此,一些存儲(chǔ)引擎可能會(huì)在特定的操作順序下發(fā)生死鎖,其他的可能沒(méi)有。死鎖有兩種:一些是因?yàn)閷?shí)際數(shù)據(jù)沖突而無(wú)法避免,一些是因?yàn)榇鎯?chǔ)引擎的工作方式產(chǎn)生。
只有部分或者完全回滾其中的一個(gè)事務(wù)才可能打破死鎖。死鎖是事務(wù)系統(tǒng)中客觀存在的事實(shí),你的應(yīng)該在設(shè)計(jì)上必須應(yīng)該考慮處理死鎖。一些業(yè)務(wù)系統(tǒng)可以從頭重試事務(wù)。
如何處理死鎖
死鎖是事務(wù)型數(shù)據(jù)庫(kù)典型的問(wèn)題,但是除非它們頻繁出現(xiàn)以至于你更本不能運(yùn)行某個(gè)事務(wù),它們一般是不危險(xiǎn)的。正常地,你必須編寫(xiě)你的應(yīng)用程序使得它們總是準(zhǔn)備如果因?yàn)樗梨i而 回滾一個(gè)事務(wù)就重新發(fā)出一個(gè)事務(wù)。
InnoDB使用自動(dòng)行級(jí)鎖定。即使在只插入或刪除單個(gè)行的事務(wù)的情況下,你可以遇到死鎖。這是因?yàn)檫@些操作不是真正的“極小的”,它們自動(dòng)對(duì)插入或刪除的行的(可能是數(shù)個(gè))索引記錄設(shè)置鎖定。
你可以用下列技術(shù)對(duì)付死鎖減少它們發(fā)生的可能性:
用Use SHOW INNODB STATUS來(lái)確定最后一個(gè)死鎖的原因。這樣可以幫助你調(diào)節(jié)應(yīng)用程序來(lái)避免死鎖。
總是準(zhǔn)備著重新發(fā)出事務(wù),如果它因?yàn)樗梨i而失敗了。死鎖不危險(xiǎn),再試一次。
經(jīng)常提交你的事務(wù)。小事務(wù)更少地傾向于沖突。
如果你正使用鎖定讀,(SELECT ... FOR UPDATE或 ... LOCK IN SHARE MODE),試著用更低的隔離級(jí)別,比如READ COMMITTED。
以固定的順序訪問(wèn)你的表和行。則事務(wù)形成良好定義的查詢(xún)并且沒(méi)有死鎖。
添加精心選定的索引到你的表。則你的查詢(xún)需要掃描更少的索引記錄并且因此設(shè)置更少的鎖定。使用EXPLAIN SELECT來(lái)確定對(duì)于你的查詢(xún),MySQL認(rèn)為哪個(gè)索引是最適當(dāng)?shù)摹?/p>
使用更少的鎖定。如果你可以接受允許一個(gè)SELECT從一個(gè)舊的快照返回?cái)?shù)據(jù),不要給它添加FOR UPDATE或LOCK IN SHARE MODE子句。這里使用READ COMMITTED隔離級(jí)別是比較好的,因?yàn)槊總€(gè)在同一事務(wù)里的持續(xù)讀從它自己新鮮的快照里讀取。
如果沒(méi)有別的有幫助的了,用表級(jí)鎖定系列化你的事務(wù)。用LOCK TABLES對(duì)事務(wù)型表(如InnoDB)的正確方法是設(shè)置AUTOCOMMIT = 0 并且不調(diào)用UNLOCK TABLES直到你明確地提交了事務(wù)。例如,如果你需要寫(xiě)表t1并從表t讀,你可以按如下做:
1
2
3
4
5
6
7
8
9
|
SET AUTOCOMMIT=0; LOCK TABLES t1 WRITE, t2 READ , ...; [do something with tables t1 and t2 here]; COMMIT ; UNLOCK TABLES; |
表級(jí)鎖定使得你的事務(wù)很好地排隊(duì),并且死鎖被避免了。
領(lǐng)一個(gè)系列化事務(wù)的方法是創(chuàng)建一個(gè)輔助的“semaphore” 表,它只包含一個(gè)單行。讓每個(gè)事務(wù)在訪問(wèn)其它表之前更新那個(gè)行。以這種方式,所有事務(wù)以序列的方式發(fā)生。注意,InnoDB即時(shí)死鎖檢測(cè)算法也能在這種情況下起租用,因?yàn)橄盗谢i定是行級(jí)鎖定。超時(shí)方法,用MySQL表級(jí)鎖定,必須被用來(lái)解決死鎖。
在應(yīng)用程序中使用LOCK TABLES命令,如果AUTOCOMMIT=1,MySQL不設(shè)定InnoDB表鎖定。