97无码人妻精品,91无码人妻精品一区二区三区蜜桃,aa级全黄毛片

主頁 > 知識庫 > 5分鐘快速了解數據庫死鎖產生的場景和解決方法

5分鐘快速了解數據庫死鎖產生的場景和解決方法

前言

加鎖（Locking）是數據庫在并發訪問時保證數據一致性和完整性的主要機制。任何事務都需要獲得相應對象上的鎖才能訪問數據，讀取數據的事務通常只需要獲得讀鎖（共享鎖），修改數據的事務需要獲得寫鎖（排他鎖）。當兩個事務互相之間需要等待對方釋放獲得的資源時，如果系統不進行干預則會一直等待下去，也就是進入了死鎖（deadlock）狀態。

以下內容適用于各種常見的數據庫管理系統，包括 Oracle、MySQL、Microsoft SQL Server 以及 PostgreSQL 等。

死鎖是如何產生的？

演示死鎖的產生非常簡單，我們只需要創建一個包含兩行數據的簡單示例表：

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|

如果我們在不同事務中以不同的順序修改數據，就可能引起事務之間的相互等待。一個事務等待另一個事務釋放資源不會產生什么問題，但是如果兩個事務互相等待對方的資源，數據庫管理系統只有兩個選擇：無限等待或者中止一個事務并讓另一個事務成功執行。

顯然無限等待不是解決問題的方法，因此數據庫通常是等待一定時間之后中止其中一個事務。

以下是一個死鎖的演示案例：

事務一	事務二	備注
BEGIN;	BEGIN;	分別開始兩個事務
UPDATE t_lock SET col = col + 100 WHERE id = 1;	UPDATE t_lock SET col = col + 200 WHERE id = 2;	事務一修改 id=1 的數據，事務二修改 id=2 的數據
UPDATE t_lock SET col = col + 100 WHERE id = 2;		事務一修改 id=2 的數據，需要等待事務二釋放寫鎖
等待中…	UPDATE t_lock SET col = col + 200 WHERE id = 1;	事務二修改 id=1 的數據，需要等待事務一釋放寫鎖
死鎖	死鎖	數據庫檢測到死鎖，選擇中止一個事務
更新成功	返回錯誤

對于 MySQL InnoDB，默認啟用了 innodb_deadlock_detect 選項，事務二返回以下錯誤信息：

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

如果我們禁用 InnoDB 死鎖檢測選項，事務二在等待 50 s（innodb_lock_wait_timeout ）后提示等待超時：

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Oracle 檢測到死鎖時返回以下錯誤：

ORA-00060: 等待資源時檢測到死鎖

Microsoft SQL Server 檢測到死鎖時返回的錯誤如下

消息 1205，級別 13，狀態 51，第 7 行
事務(進程 ID 67)與另一個進程被死鎖在鎖資源上，并且已被選作死鎖犧牲品。請重新運行該事務。

PostgreSQL 檢測到死鎖時返回的錯誤如下：

SQL 錯誤 [40P01]: 錯誤: 檢測到死鎖
詳細：進程32等待在事務 4765上的ShareLock; 由進程16552阻塞.
進程16552等待在事務 4766上的ShareLock; 由進程32阻塞.
建議：詳細信息請查看服務器日志.
在位置：當更新關系"t_lock"的元組(0, 1)時

如何解決并避免死鎖

死鎖不是數據庫自身的問題，我們無法通過優化數據庫配置來解決或者避免死鎖，只能通過修改應用程序來解決。簡單來說，我們應該在程序中按照相同的順序修改數據，避免產生相互等待資源的情況發生。例如：

事務一	事務二	備注
BEGIN;	BEGIN;	分別開始兩個事務
UPDATE t_lock SET col = col + 100 WHERE id = 1;	UPDATE t_lock SET col = col + 200 WHERE id = 1;	事務一和事務二都修改 id=1 的數據，后執行的事務需要等待
UPDATE t_lock SET col = col + 100 WHERE id = 2;	等待中…	事務一修改 id=1 的數據，事務二等待中
COMMIT;	等待中…	事務一提交
	UPDATE t_lock SET col = col + 200 WHERE id = 2;	事務二繼續修改 id=2 的數據
	COMMIT;	事務二提交