婷婷综合国产,91蜜桃婷婷狠狠久久综合9色 ,九九九九九精品,国产综合av

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

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

熱門標簽:400電話申請怎么看 hbuilder地圖標注 天音通信電話機器人 杭州400電話如何申請的 高德地圖標注商家在哪 江西南昌百應電話機器人 機器人電話機創意繪畫 隨州營銷電話機器人怎么樣 400電話從哪里申請濱州

前言

加鎖(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; 事務二提交

以上場景不會產生死鎖。不過,我們在實際應用中可能無法完全按照相同順序修改數據。如果出現了不可避免的死鎖情況,另一種解決方法就是捕獲系統返回的死鎖異常并在程序中加入重試機制。

總結

本文簡要介紹了數據庫死鎖產生的原因和解決方法。到此這篇關于5分鐘快速了解數據庫死鎖產生的場景和解決方法的文章就介紹到這了,更多相關數據庫死鎖內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家!

您可能感興趣的文章:
  • mysql 數據庫死鎖原因及解決辦法
  • Mysql 數據庫死鎖過程分析(select for update)
  • 簡單說明Oracle數據庫中對死鎖的查詢及解決方法
  • InnoDB數據庫死鎖問題處理
  • Mybatis update數據庫死鎖之獲取數據庫連接池等待
  • MySQL數據庫的一次死鎖實例分析
  • 講解Oracle數據庫中結束死鎖進程的一般方法
  • 記一次公司倉庫數據庫服務器死鎖過程及解決辦法
  • 查詢Sqlserver數據庫死鎖的一個存儲過程分享
  • MySQL數據庫之Purge死鎖問題解析

標簽:鶴崗 常德 昆明 葫蘆島 沈陽 石嘴山 招商 保定

巨人網絡通訊聲明:本文標題《5分鐘快速了解數據庫死鎖產生的場景和解決方法》,本文關鍵詞  5分鐘,快速,了解,數據庫,;如發現本文內容存在版權問題,煩請提供相關信息告之我們,我們將及時溝通與處理。本站內容系統采集于網絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《5分鐘快速了解數據庫死鎖產生的場景和解決方法》相關的同類信息!
  • 本頁收集關于5分鐘快速了解數據庫死鎖產生的場景和解決方法的相關信息資訊供網民參考!
  • 推薦文章
    主站蜘蛛池模板: 泸西县| 陆川县| 浪卡子县| 蒲江县| 屯门区| 德惠市| 鄱阳县| 郯城县| 南京市| 清水河县| 太保市| 江山市| 思茅市| 嵩明县| 贡嘎县| 临夏县| 遂平县| 兰溪市| 河东区| 崇仁县| 台北市| 孟州市| 南涧| 哈尔滨市| 弥渡县| 北京市| 冷水江市| 平山县| 周宁县| 怀化市| 信宜市| 永泰县| 沈丘县| 蚌埠市| 黄大仙区| 盐边县| 昌平区| 衡阳县| 禹城市| 泾阳县| 阿拉善盟|