MySQLInnoDB如何應(yīng)付死鎖
死鎖是事務(wù)處理型數(shù)據(jù)庫系統(tǒng)的一個經(jīng)典問題，但是它們并不是很危險的， 除非它們?nèi)绱说仡l繁以至于你根本處理不了幾個事務(wù)。 當(dāng)因死鎖而產(chǎn)生了回滾時，你通?？梢栽谀愕膽?yīng)用程序中重新發(fā)出一個事務(wù)即可。
InnoDB 使用自動地行級鎖定。你可能恰好在插入或刪除單一一條記錄時產(chǎn)生死鎖。 這是因?yàn)檫@些操作并不是真正“原子(atomic)”級的：他們會自動地在鎖定 inserted/deleted 行的索引記錄(可能有幾個)。
可以通過下面所示的技巧來應(yīng)付死鎖或減少死鎖的次數(shù)：
在 MySQL >=3.23.52 和 >= 4.0.3 的版本中使用 SHOW INNODB STATUS 來確定引起最后一個死鎖的原因。這可以幫助你調(diào)整你的應(yīng)用程序來避免死鎖。
總是準(zhǔn)備在因死鎖而發(fā)生錯誤時重新發(fā)出一個事務(wù)。死鎖并不危險。僅僅只需重試一遍。
經(jīng)常提交你的事務(wù)。小的事務(wù)有較少的碰撞可能。
如果使用鎖定讀取 SELECT ... FOR UPDATE 或 ... LOCK IN SHARE MODE，盡量使用較低的隔離級 READ COMMITTED。
以一個固定秩序(a fixed order)訪問你的表和記錄。這樣事務(wù)將形成一個較精細(xì)的隊列，而避免死鎖。
為你的表添加合適的索引。那么你的查詢只需要掃描較少的索引，因而設(shè)置較少的鎖定。使用 EXPLAIN SELECT 來確定 MySQL 為你的查詢挑選的適當(dāng)?shù)乃饕?nbsp;
盡量少用鎖定：如果可以通過一個 SELECT 在一個較老的數(shù)據(jù)快照中獲得所需數(shù)據(jù)，就不要再添加子句 FOR UPDATE 或 LOCK IN SHARE MODE 。在這時使用 READ COMMITTED 隔離級是較好的主意，因?yàn)樵谕粋€事務(wù)中的每個 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ì)的隊列。注意 LOCK TABLES 隱含地啟動一個事務(wù)，就如同命令 BEGIN，UNLOCK TABLES 如同 COMMIT 一樣隱含地結(jié)束一個事務(wù)。
連載事務(wù)(serialize transactions)的另一個解決辦法就是建立一個僅有一行記錄的輔助“信號量(semaphore)” 表。每一個事務(wù)在訪問其它表之前均更新這個記錄。通過這種方式所有的事務(wù)將持續(xù)執(zhí)行。注意同時 InnoDB 實(shí)時死鎖檢測算法也在工作著，因?yàn)檫@個持續(xù)鎖定(serializing lock)是一個行鎖定。在 MySQL 中對于表級鎖定我們必須采取超時方式。
死鎖檢測與回滾
InnoDB 會自動檢測一個事務(wù)的死鎖并回滾一個或多個事務(wù)來防止死鎖。從 4.0.5 版開始，InnoDB 將設(shè)法提取小的事務(wù)來進(jìn)行回滾。一個事務(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í)行一個事務(wù)完整的回滾，這個事務(wù)所有所加的鎖將被釋放。然而，如果只一句的 SQL 語句因結(jié)果返回錯誤而進(jìn)行回滾的，由這條 SQL 語句所設(shè)置的鎖定可能會被保持。這是因?yàn)?InnoDB r的行鎖存儲格式無法知道鎖定是由哪個 SQL 語句所設(shè)置。
InnoDB 使用自動地行級鎖定。你可能恰好在插入或刪除單一一條記錄時產(chǎn)生死鎖。 這是因?yàn)檫@些操作并不是真正“原子(atomic)”級的：他們會自動地在鎖定 inserted/deleted 行的索引記錄(可能有幾個)。
可以通過下面所示的技巧來應(yīng)付死鎖或減少死鎖的次數(shù)：
在 MySQL >=3.23.52 和 >= 4.0.3 的版本中使用 SHOW INNODB STATUS 來確定引起最后一個死鎖的原因。這可以幫助你調(diào)整你的應(yīng)用程序來避免死鎖。
總是準(zhǔn)備在因死鎖而發(fā)生錯誤時重新發(fā)出一個事務(wù)。死鎖并不危險。僅僅只需重試一遍。
經(jīng)常提交你的事務(wù)。小的事務(wù)有較少的碰撞可能。
如果使用鎖定讀取 SELECT ... FOR UPDATE 或 ... LOCK IN SHARE MODE，盡量使用較低的隔離級 READ COMMITTED。
以一個固定秩序(a fixed order)訪問你的表和記錄。這樣事務(wù)將形成一個較精細(xì)的隊列，而避免死鎖。
為你的表添加合適的索引。那么你的查詢只需要掃描較少的索引，因而設(shè)置較少的鎖定。使用 EXPLAIN SELECT 來確定 MySQL 為你的查詢挑選的適當(dāng)?shù)乃饕?nbsp;
盡量少用鎖定：如果可以通過一個 SELECT 在一個較老的數(shù)據(jù)快照中獲得所需數(shù)據(jù)，就不要再添加子句 FOR UPDATE 或 LOCK IN SHARE MODE 。在這時使用 READ COMMITTED 隔離級是較好的主意，因?yàn)樵谕粋€事務(wù)中的每個 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ì)的隊列。注意 LOCK TABLES 隱含地啟動一個事務(wù)，就如同命令 BEGIN，UNLOCK TABLES 如同 COMMIT 一樣隱含地結(jié)束一個事務(wù)。
連載事務(wù)(serialize transactions)的另一個解決辦法就是建立一個僅有一行記錄的輔助“信號量(semaphore)” 表。每一個事務(wù)在訪問其它表之前均更新這個記錄。通過這種方式所有的事務(wù)將持續(xù)執(zhí)行。注意同時 InnoDB 實(shí)時死鎖檢測算法也在工作著，因?yàn)檫@個持續(xù)鎖定(serializing lock)是一個行鎖定。在 MySQL 中對于表級鎖定我們必須采取超時方式。
死鎖檢測與回滾
InnoDB 會自動檢測一個事務(wù)的死鎖并回滾一個或多個事務(wù)來防止死鎖。從 4.0.5 版開始，InnoDB 將設(shè)法提取小的事務(wù)來進(jìn)行回滾。一個事務(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í)行一個事務(wù)完整的回滾，這個事務(wù)所有所加的鎖將被釋放。然而，如果只一句的 SQL 語句因結(jié)果返回錯誤而進(jìn)行回滾的，由這條 SQL 語句所設(shè)置的鎖定可能會被保持。這是因?yàn)?InnoDB r的行鎖存儲格式無法知道鎖定是由哪個 SQL 語句所設(shè)置。
當(dāng)前題目：MySQLInnoDB如何應(yīng)付死鎖
鏈接地址：http://jinyejixie.com/article22/pggicc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、做網(wǎng)站、網(wǎng)站設(shè)計公司、軟件開發(fā)、ChatGPT、營銷型網(wǎng)站建設(shè)
聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)
