5分鐘快速了解數(shù)據(jù)庫死鎖產(chǎn)生的場景和解決方法
加鎖（Locking）是數(shù)據(jù)庫在并發(fā)訪問時保證數(shù)據(jù)一致性和完整性的主要機(jī)制。任何事務(wù)都需要獲得相應(yīng)對象上的鎖才能訪問數(shù)據(jù)，讀取數(shù)據(jù)的事務(wù)通常只需要獲得讀鎖（共享鎖），修改數(shù)據(jù)的事務(wù)需要獲得寫鎖（排他鎖）。當(dāng)兩個事務(wù)互相之間需要等待對方釋放獲得的資源時，如果系統(tǒng)不進(jìn)行干預(yù)則會一直等待下去，也就是進(jìn)入了死鎖（deadlock）狀態(tài)。
以下內(nèi)容適用于各種常見的數(shù)據(jù)庫管理系統(tǒng)，包括 Oracle、MySQL、Microsoft SQL Server 以及 PostgreSQL 等。
死鎖是如何產(chǎn)生的？
演示死鎖的產(chǎn)生非常簡單，我們只需要創(chuàng)建一個包含兩行數(shù)據(jù)的簡單示例表：
CREATE TABLE t_lock(id int PRIMARY KEY, col int); INSERT INTO t_lock VALUES (1, 100); INSERT INTO t_lock VALUES (2, 200); SELECT * FROM t_lock; id|col| --+---+ 1|100| 2|200|
如果我們在不同事務(wù)中以不同的順序修改數(shù)據(jù)，就可能引起事務(wù)之間的相互等待。一個事務(wù)等待另一個事務(wù)釋放資源不會產(chǎn)生什么問題，但是如果兩個事務(wù)互相等待對方的資源，數(shù)據(jù)庫管理系統(tǒng)只有兩個選擇：無限等待或者中止一個事務(wù)并讓另一個事務(wù)成功執(zhí)行。
顯然無限等待不是解決問題的方法，因此數(shù)據(jù)庫通常是等待一定時間之后中止其中一個事務(wù)。
以下是一個死鎖的演示案例：
| 事務(wù)一 | 事務(wù)二 | 備注 |
|---|---|---|
| BEGIN; | BEGIN; | 分別開始兩個事務(wù) |
| UPDATE t_lock SET col = col + 100 WHERE id = 1; |
UPDATE t_lock SET col = col + 200 WHERE id = 2; |
事務(wù)一修改 id=1 的數(shù)據(jù)，事務(wù)二修改 id=2 的數(shù)據(jù) |
| UPDATE t_lock SET col = col + 100 WHERE id = 2; |
事務(wù)一修改 id=2 的數(shù)據(jù)，需要等待事務(wù)二釋放寫鎖 | |
| 等待中… | UPDATE t_lock SET col = col + 200 WHERE id = 1; |
事務(wù)二修改 id=1 的數(shù)據(jù)，需要等待事務(wù)一釋放寫鎖 |
| 死鎖 | 死鎖 | 數(shù)據(jù)庫檢測到死鎖，選擇中止一個事務(wù) |
| 更新成功 | 返回錯誤 |
對于 MySQL InnoDB，默認(rèn)啟用了 innodb_deadlock_detect 選項(xiàng)，事務(wù)二返回以下錯誤信息：
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
如果我們禁用 InnoDB 死鎖檢測選項(xiàng)，事務(wù)二在等待 50 s（innodb_lock_wait_timeout ）后提示等待超時：
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
Oracle 檢測到死鎖時返回以下錯誤：
ORA-00060: 等待資源時檢測到死鎖
Microsoft SQL Server 檢測到死鎖時返回的錯誤如下
消息 1205，級別 13，狀態(tài) 51，第 7 行
事務(wù)(進(jìn)程 ID 67)與另一個進(jìn)程被死鎖在 鎖 資源上，并且已被選作死鎖犧牲品。請重新運(yùn)行該事務(wù)。
PostgreSQL 檢測到死鎖時返回的錯誤如下：
SQL 錯誤 [40P01]: 錯誤: 檢測到死鎖
詳細(xì)：進(jìn)程32等待在事務(wù) 4765上的ShareLock; 由進(jìn)程16552阻塞.
進(jìn)程16552等待在事務(wù) 4766上的ShareLock; 由進(jìn)程32阻塞.
建議：詳細(xì)信息請查看服務(wù)器日志.
在位置：當(dāng)更新關(guān)系"t_lock"的元組(0, 1)時
如何解決并避免死鎖
死鎖不是數(shù)據(jù)庫自身的問題，我們無法通過優(yōu)化數(shù)據(jù)庫配置來解決或者避免死鎖，只能通過修改應(yīng)用程序來解決。簡單來說，我們應(yīng)該在程序中按照相同的順序修改數(shù)據(jù)，避免產(chǎn)生相互等待資源的情況發(fā)生。例如：
| 事務(wù)一 | 事務(wù)二 | 備注 |
|---|---|---|
| BEGIN; | BEGIN; | 分別開始兩個事務(wù) |
| UPDATE t_lock SET col = col + 100 WHERE id = 1; |
UPDATE t_lock SET col = col + 200 WHERE id = 1; |
事務(wù)一和事務(wù)二都修改 id=1 的數(shù)據(jù)，后執(zhí)行的事務(wù)需要等待 |
| UPDATE t_lock SET col = col + 100 WHERE id = 2; |
等待中… | 事務(wù)一修改 id=1 的數(shù)據(jù)，事務(wù)二等待中 |
| COMMIT; | 等待中… | 事務(wù)一提交 |
| UPDATE t_lock SET col = col + 200 WHERE id = 2; |
事務(wù)二繼續(xù)修改 id=2 的數(shù)據(jù) | |
| COMMIT; | 事務(wù)二提交 |
以上場景不會產(chǎn)生死鎖。不過，我們在實(shí)際應(yīng)用中可能無法完全按照相同順序修改數(shù)據(jù)。如果出現(xiàn)了不可避免的死鎖情況，另一種解決方法就是捕獲系統(tǒng)返回的死鎖異常并在程序中加入重試機(jī)制。
總結(jié)
本文簡要介紹了數(shù)據(jù)庫死鎖產(chǎn)生的原因和解決方法。到此這篇關(guān)于5分鐘快速了解數(shù)據(jù)庫死鎖產(chǎn)生的場景和解決方法的文章就介紹到這了,更多相關(guān)數(shù)據(jù)庫死鎖內(nèi)容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站！
版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。
關(guān)注官方微信