死鎖是事務(wù)處理型數(shù)據(jù)庫系統(tǒng)的一個(gè)經(jīng)典問題，但是它們并不是很危險(xiǎn)的， 除非它們?nèi)绱说仡l繁以至于你根本處理不了幾個(gè)事務(wù)。 當(dāng)因死鎖而產(chǎn)生了回滾時(shí)，你通?？梢栽谀愕膽?yīng)用程序中重新發(fā)出一個(gè)事務(wù)即可。

InnoDB 使用自動地行級鎖定。你可能恰好在插入或刪除單一一條記錄時(shí)產(chǎn)生死鎖。 這是因?yàn)檫@些操作并不是真正“原子(atomic)”級的：他們會自動地在鎖定 inserted/deleted 行的索引記錄(可能有幾個(gè))。


可以通過下面所示的技巧來應(yīng)付死鎖或減少死鎖的次數(shù)： 

在 MySQL >=3.23.52 和 >= 4.0.3 的版本中使用 SHOW INNODB STATUS 來確定引起最后一個(gè)死鎖的原因。這可以幫助你調(diào)整你的應(yīng)用程序來避免死鎖。 
總是準(zhǔn)備在因死鎖而發(fā)生錯(cuò)誤時(shí)重新發(fā)出一個(gè)事務(wù)。死鎖并不危險(xiǎn)。僅僅只需重試一遍。 
經(jīng)常提交你的事務(wù)。小的事務(wù)有較少的碰撞可能。 
如果使用鎖定讀取 SELECT ... FOR UPDATE 或 ... LOCK IN SHARE MODE，盡量使用較低的隔離級 READ COMMITTED。 
以一個(gè)固定秩序(a fixed order)訪問你的表和記錄。這樣事務(wù)將形成一個(gè)較精細(xì)的隊(duì)列，而避免死鎖。 
為你的表添加合適的索引。那么你的查詢只需要掃描較少的索引，因而設(shè)置較少的鎖定。使用 EXPLAIN SELECT 來確定 MySQL 為你的查詢挑選的適當(dāng)?shù)乃饕?nbsp;
盡量少用鎖定：如果可以通過一個(gè) SELECT 在一個(gè)較老的數(shù)據(jù)快照中獲得所需數(shù)據(jù)，就不要再添加子句 FOR UPDATE 或 LOCK IN SHARE MODE 。在這時(shí)使用 READ COMMITTED 隔離級是較好的主意，因?yàn)樵谕粋€(gè)事務(wù)中的每個(gè) consistent read 只讀取它最先確定的數(shù)據(jù)快照。 
如果仍然沒有什么補(bǔ)救效果，使用表級鎖定連載你的事務(wù)(serialize transactions)：LOCK TABLES t1 WRITE, t2 READ, ... ; [do something with tables t1 and t2 here]; UNLOCK TABLES。表級鎖定可以使你的事務(wù)形成精細(xì)的隊(duì)列。注意 LOCK TABLES 隱含地啟動一個(gè)事務(wù)，就如同命令 BEGIN，UNLOCK TABLES 如同 COMMIT 一樣隱含地結(jié)束一個(gè)事務(wù)。 
連載事務(wù)(serialize transactions)的另一個(gè)解決辦法就是建立一個(gè)僅有一行記錄的輔助“信號量(semaphore)” 表。每一個(gè)事務(wù)在訪問其它表之前均更新這個(gè)記錄。通過這種方式所有的事務(wù)將持續(xù)執(zhí)行。注意同時(shí) InnoDB 實(shí)時(shí)死鎖檢測算法也在工作著，因?yàn)檫@個(gè)持續(xù)鎖定(serializing lock)是一個(gè)行鎖定。在 MySQL 中對于表級鎖定我們必須采取超時(shí)方式。 


死鎖檢測與回滾
InnoDB 會自動檢測一個(gè)事務(wù)的死鎖并回滾一個(gè)或多個(gè)事務(wù)來防止死鎖。從 4.0.5 版開始，InnoDB 將設(shè)法提取小的事務(wù)來進(jìn)行回滾。一個(gè)事務(wù)的大小由它所插入(insert)、更新(update)和刪除(delete)的數(shù)據(jù)行數(shù)決定。 Previous to 4.0.5, InnoDB always rolled back the transaction whose lock request was the last one to build a deadlock, that is, a cycle in the waits-for graph of transactions.

InnoDB 不能檢測出由 MySQL 的 LOCK TABLES 語句引起的死鎖，或其它的表類型中的鎖定所引起的死鎖。你不得不通過在 my.cnf 中設(shè)置 innodb_lock_wait_timeout 參數(shù)來解決這些情形。

當(dāng) InnoDB 執(zhí)行一個(gè)事務(wù)完整的回滾，這個(gè)事務(wù)所有所加的鎖將被釋放。然而，如果只一句的 SQL 語句因結(jié)果返回錯(cuò)誤而進(jìn)行回滾的，由這條 SQL 語句所設(shè)置的鎖定可能會被保持。這是因?yàn)?InnoDB r的行鎖存儲格式無法知道鎖定是由哪個(gè) SQL 語句所設(shè)置。




當(dāng)前名稱：MySQLInnoDB如何應(yīng)付死鎖
分享網(wǎng)址：http://weahome.cn/article/pggicc.html