5分鐘快速了解數(shù)據(jù)庫(kù)死鎖產(chǎn)生的場(chǎng)景和解決方法
前言
加鎖(Locking)是數(shù)據(jù)庫(kù)在并發(fā)訪問時(shí)保證數(shù)據(jù)一致性和完整性的主要機(jī)制。任何事務(wù)都需要獲得相應(yīng)對(duì)象上的鎖才能訪問數(shù)據(jù),讀取數(shù)據(jù)的事務(wù)通常只需要獲得讀鎖(共享鎖),修改數(shù)據(jù)的事務(wù)需要獲得寫鎖(排他鎖)。當(dāng)兩個(gè)事務(wù)互相之間需要等待對(duì)方釋放獲得的資源時(shí),如果系統(tǒng)不進(jìn)行干預(yù)則會(huì)一直等待下去,也就是進(jìn)入了死鎖(deadlock)狀態(tài)。
以下內(nèi)容適用于各種常見的數(shù)據(jù)庫(kù)管理系統(tǒng),包括 Oracle、MySQL、Microsoft SQL Server 以及 PostgreSQL 等。
死鎖是如何產(chǎn)生的?
演示死鎖的產(chǎn)生非常簡(jiǎn)單,我們只需要?jiǎng)?chuàng)建一個(gè)包含兩行數(shù)據(jù)的簡(jiǎn)單示例表:
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|
如果我們?cè)诓煌聞?wù)中以不同的順序修改數(shù)據(jù),就可能引起事務(wù)之間的相互等待。一個(gè)事務(wù)等待另一個(gè)事務(wù)釋放資源不會(huì)產(chǎn)生什么問題,但是如果兩個(gè)事務(wù)互相等待對(duì)方的資源,數(shù)據(jù)庫(kù)管理系統(tǒng)只有兩個(gè)選擇:無(wú)限等待或者中止一個(gè)事務(wù)并讓另一個(gè)事務(wù)成功執(zhí)行。
顯然無(wú)限等待不是解決問題的方法,因此數(shù)據(jù)庫(kù)通常是等待一定時(shí)間之后中止其中一個(gè)事務(wù)。
以下是一個(gè)死鎖的演示案例:
| 事務(wù)一 | 事務(wù)二 | 備注 |
|---|---|---|
| BEGIN; | BEGIN; | 分別開始兩個(gè)事務(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ù)庫(kù)檢測(cè)到死鎖,選擇中止一個(gè)事務(wù) |
| 更新成功 | 返回錯(cuò)誤 |
對(duì)于 MySQL InnoDB,默認(rèn)啟用了 innodb_deadlock_detect 選項(xiàng),事務(wù)二返回以下錯(cuò)誤信息:
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
如果我們禁用 InnoDB 死鎖檢測(cè)選項(xiàng),事務(wù)二在等待 50 s(innodb_lock_wait_timeout )后提示等待超時(shí):
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
Oracle 檢測(cè)到死鎖時(shí)返回以下錯(cuò)誤:
ORA-00060: 等待資源時(shí)檢測(cè)到死鎖
Microsoft SQL Server 檢測(cè)到死鎖時(shí)返回的錯(cuò)誤如下
消息 1205,級(jí)別 13,狀態(tài) 51,第 7 行
事務(wù)(進(jìn)程 ID 67)與另一個(gè)進(jìn)程被死鎖在 鎖 資源上,并且已被選作死鎖犧牲品。請(qǐng)重新運(yùn)行該事務(wù)。
PostgreSQL 檢測(cè)到死鎖時(shí)返回的錯(cuò)誤如下:
SQL 錯(cuò)誤 [40P01]: 錯(cuò)誤: 檢測(cè)到死鎖
詳細(xì):進(jìn)程32等待在事務(wù) 4765上的ShareLock; 由進(jìn)程16552阻塞.
進(jìn)程16552等待在事務(wù) 4766上的ShareLock; 由進(jìn)程32阻塞.
建議:詳細(xì)信息請(qǐng)查看服務(wù)器日志.
在位置:當(dāng)更新關(guān)系"t_lock"的元組(0, 1)時(shí)
如何解決并避免死鎖
死鎖不是數(shù)據(jù)庫(kù)自身的問題,我們無(wú)法通過優(yōu)化數(shù)據(jù)庫(kù)配置來(lái)解決或者避免死鎖,只能通過修改應(yīng)用程序來(lái)解決。簡(jiǎn)單來(lái)說,我們應(yīng)該在程序中按照相同的順序修改數(shù)據(jù),避免產(chǎn)生相互等待資源的情況發(fā)生。例如:
| 事務(wù)一 | 事務(wù)二 | 備注 |
|---|---|---|
| BEGIN; | BEGIN; | 分別開始兩個(gè)事務(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ǎng)景不會(huì)產(chǎn)生死鎖。不過,我們?cè)趯?shí)際應(yīng)用中可能無(wú)法完全按照相同順序修改數(shù)據(jù)。如果出現(xiàn)了不可避免的死鎖情況,另一種解決方法就是捕獲系統(tǒng)返回的死鎖異常并在程序中加入重試機(jī)制。
總結(jié)
本文簡(jiǎn)要介紹了數(shù)據(jù)庫(kù)死鎖產(chǎn)生的原因和解決方法。到此這篇關(guān)于5分鐘快速了解數(shù)據(jù)庫(kù)死鎖產(chǎn)生的場(chǎng)景和解決方法的文章就介紹到這了,更多相關(guān)數(shù)據(jù)庫(kù)死鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- mysql 數(shù)據(jù)庫(kù)死鎖原因及解決辦法
- Mysql 數(shù)據(jù)庫(kù)死鎖過程分析(select for update)
- 簡(jiǎn)單說明Oracle數(shù)據(jù)庫(kù)中對(duì)死鎖的查詢及解決方法
- InnoDB數(shù)據(jù)庫(kù)死鎖問題處理
- Mybatis update數(shù)據(jù)庫(kù)死鎖之獲取數(shù)據(jù)庫(kù)連接池等待
- MySQL數(shù)據(jù)庫(kù)的一次死鎖實(shí)例分析
- 講解Oracle數(shù)據(jù)庫(kù)中結(jié)束死鎖進(jìn)程的一般方法
- 記一次公司倉(cāng)庫(kù)數(shù)據(jù)庫(kù)服務(wù)器死鎖過程及解決辦法
- 查詢Sqlserver數(shù)據(jù)庫(kù)死鎖的一個(gè)存儲(chǔ)過程分享
- MySQL數(shù)據(jù)庫(kù)之Purge死鎖問題解析
相關(guān)文章
influxdb數(shù)據(jù)庫(kù)常用命令及SpringBoot整合
這篇文章主要介紹了influxdb數(shù)據(jù)庫(kù)常用命令及SpringBoot整合,Influxdb是一個(gè)開源的分布式時(shí)序、時(shí)間和指標(biāo)數(shù)據(jù)庫(kù),使用go語(yǔ)言編寫,無(wú)需外部依賴,需要的朋友可以參考下2023-07-07
數(shù)據(jù)庫(kù)查詢優(yōu)化(主從表的設(shè)計(jì))
寫過許多的數(shù)據(jù)庫(kù)查詢語(yǔ)句,面對(duì)過許多的問題,也在磕磕碰碰中學(xué)到了很多東西。昨天在看系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)與SQL代碼時(shí),突然“發(fā)現(xiàn)”了許多平常不屑看到的問題,于是就萌生了把它提出來(lái)思考的念頭2013-08-08
Hadoop2.X/YARN環(huán)境搭建--CentOS7.0 JDK配置
在Centos中,進(jìn)行配置jdk的環(huán)境,這個(gè)還是折騰了我聽挺久的。特別是在一次配置中,導(dǎo)致后來(lái)我的root用戶無(wú)法登錄,并且用其他普通用戶登錄,使用su - root切換到root用戶,都無(wú)法使用ls這一些普通的命令。由于沒有權(quán)限,各種更改,都沒轍。各種麻煩啊~2014-08-08
海量數(shù)據(jù)庫(kù)的查詢優(yōu)化及分頁(yè)算法方案集合1/2
海量數(shù)據(jù)庫(kù)的查詢優(yōu)化及分頁(yè)算法方案集合1/2...2007-03-03
舉例簡(jiǎn)單介紹PostgreSQL中的數(shù)組
這篇文章主要介紹了舉例簡(jiǎn)單介紹PostgreSQL中的數(shù)組,PostgreSQL是一個(gè)高性能關(guān)系型數(shù)據(jù)庫(kù),學(xué)習(xí)PostgreSQL將成為趨勢(shì),需要的朋友可以參考下2015-04-04

