2020-07-08：mysql只有一個表a，什么情況下會造成死鎖，解決辦法是什么？

你好，很高興回答你的問題。

成都創新互聯是一家集網站建設,祁東企業網站建設,祁東品牌網站建設,網站定制,祁東網站建設報價,網絡營銷,網絡優化,祁東網站推廣為一體的創新建站企業，幫助傳統企業提升企業形象加強企業競爭力。可充分滿足這一群體相比中小企業更為豐富、高端、多元的互聯網需求。同時我們時刻保持專業、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們為更多的企業打造出實用型網站。

兩個事務t1和t2，假如t1先對表a的記錄a1加了鎖，而t2對表a的記錄a2加了鎖。

然后t1又需要對a2加鎖，t2又需要對a1加鎖。

這時候就會因為持有對方需要的鎖，而又等待對方釋放自己需要的鎖，導致死鎖。

比如兩個賬戶記錄轉賬，兩個事務，一個事務是從a轉賬給b，一個事務是從b轉賬給a。如果如果都是先給轉出賬戶（或轉入賬戶）加鎖，然后給轉入賬戶（或轉出賬戶）加鎖。就可能出現死鎖。

這個可以通過加鎖時都是先給主鍵值小的記錄加鎖，然后給主鍵值大的記錄加鎖，就會避免出現死鎖了。

如果有幫助到你，請點擊采納。

我解答的大部分是軟件開發新人遇到的問題，如果有興趣可以關注我。

mysql 死鎖排查

一、show ENGINE INNODB status

查看死鎖位置，分析。

二、

首先解決死鎖可以從死鎖發生的條件入手，最容易解決的就是更改獲取資源的順序；

其次是避免長事務，讓事務執行的時間盡可能少，讓事務的覆蓋范圍盡可能小，長事務會導致并發度降低，且會有更多的SQL查 詢延遲；

給整個方法加事務是否是必須的？可以不加事務的盡量不加。

詳解MySQL（InnoDB）如何處理死鎖

鎖是需要事務結束后才釋放的。

一個是 MVCC，一個是兩階段鎖協議。

為什么要并發控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發性能并且要求如同多個用戶的請求過來之后如同串行執行的一樣（為了解決臟讀、不可重復讀、幻讀）

官方定義：

兩階段鎖協議是指所有事務必須分兩個階段對數據加鎖和解鎖，在對任何數據進行讀、寫操作之前，事務首先要獲得對該數據的封鎖；在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖。

對應到 MySQL 上分為兩個階段：

但是兩階段鎖協議不要求事務必須一次將所有需要使用的數據加鎖（innodb在需要的索引列數據才鎖行），并且在加鎖階段沒有順序要求，所以這種并發控制方式會形成死鎖。

MySQL有兩種死鎖處理方式：

死鎖檢測 （默認開啟）

死鎖檢測的原理是構建一個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環，存在即有死鎖。

回滾

檢測到死鎖之后，選擇插入更新或者刪除的行數最少的事務回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。

收集死鎖信息：

減少死鎖：

死鎖解決：

解決一次mysql死鎖問題

多線程開啟事務處理。每個事務有多個update操作和一個insert操作（都在同一張表）。

默認隔離級別：Repeatable Read

只有hotel_id=2和hotel_id=11111的數據

邏輯刪除原有數據

插入新的數據

根據現有數據情況，update的時候沒有數據被更新

報了非常多一樣的錯

發現居然有死鎖。

根據常識考慮，我每個線程（事務）更新的數據都不沖突，為什么會產生死鎖？

帶著這個問題，打印mysql最近一次的死鎖信息

show engine innodb status

顯示如下

發現事務1在等待一個鎖

事務2也在等待一個鎖

而且事物2持有了事物1需要的鎖

關于鎖的描述，出現了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關于mysql的鎖相關的知識儲備還不夠。那就開始調查mysql的鎖相關知識。

通過搜索引擎，

鎖的持有兼容程度如下表

那么再回到死鎖日志，可以知道 :

事務1正在獲取插入意向鎖

事務2正在獲取插入意向鎖，持有排他gap鎖

再看我們上面的鎖兼容表格，可以知道， gap lock和insert intention lock是不兼容的

那么就可以推斷出： 事務1持有gap lock，等待事務2的insert intention lock釋放；事務2持有gap lock，等待事務1的insert intention lock釋放，從而導致死鎖。

那么新的問題就來了，事務1的intention lock 為什么會和事務2的gap lock 有交集，或者說，事務1要插入的數據的位置為什么會被事務2給鎖住？

讓我回顧一下gap lock的定義：

間隙鎖，鎖定一個范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務的兩次當前讀，出現幻讀的情況

那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發現自己相關的知識儲備還不夠。那就開始調查。

調查后發現，當當前索引是一個 普通索引 的時候，會加一個gap lock來防止幻讀， 此gap lock 會鎖住一個左開右閉的區間。 假設索引為xx_idx（xx_id），數據分布為1,4,6,8,12，當更新xx_id=9的時候，這個時候gap lock的鎖定記錄區間就是(8，12]，也就是鎖住了xxid in (9,10,11,12)的數據，當有其他事務要插入xxid in (9,10,11,12)的數據時，就會處于等待獲取鎖的狀態。

ps：當前索引不是普通索引，而且是唯一索引等其他情況，請參考下面資料

MySQL 加鎖處理分析

回到我自己的案例中，重新屢一下事務1的執行過程：

因為普通索引

KEY hotel_date_idx ( hotel_id , rate_date )

的關系 這段sql會獲取一個gap lock，范圍(2,11111]

這段sql會獲取一個insert intention lock （waiting）

再看事務2的執行過程

因為普通索引

KEY hotel_date_idx ( hotel_id , rate_date )

的關系 這段sql也會獲取一個gap lock，范圍也是(2,11111]（根據前面的知識，gap lock之間會互相兼容，可以一起持有鎖的）

這段sql也會獲取一個insert intention lock （waiting）

看到這里，基本也就破案了。因為普通索引的關系，事務1和事務2的gap lock的覆蓋范圍太廣，導致其他事務無法插入數據。

重新梳理一下：

所以從結果來看，一堆事務被回滾，只有10007數據被更新成功

gap lock 導致了并發處理的死鎖

在mysql默認的事務隔離級別（repeatable read）下，無法避免這種情況。只能把并發處理改成同步處理。或者從業務層面做處理。

共享鎖、排他鎖、意向共享、意向排他

record lock、gap lock、next key lock、insert intention lock

show engine innodb status

mysql死鎖場景整理

本文死鎖場景皆為工作中遇到（或同事遇到）并解決的死鎖場景，寫這篇文章的目的是整理和分享，歡迎指正和補充，本文死鎖場景包括：

注 ：以下場景隔離級別均為默認的Repeatable Read；

前提 ：表 t_user 的 uid 字段創建了唯一索引，并擁有可更新字段age。

場景復現 ：

相應業務案例和解決方案 ：

該場景常見于事務中存在for循環更新某條記錄的情況，死鎖日志顯示 lock_mode X locks rec but not gap waiting （即行鎖而非間隙鎖），解決方案：

表結構 :

場景復現 ：

首先查詢表中目前存在的記錄：

執行兩個事務的操作：

死鎖原因分析 ：

解決方案 ：

t_user結構改造為：

場景復現操作（幾率不高） ：

假設存在以下數據 ：

死鎖分析 ：

事務1 ：

① 鎖住zone_id=1對應的間隙鎖: zoneId in (1,2)

② 鎖住索引zone_id=1對應的主鍵索引行鎖id = [1,2]

③ 鎖住uid=1對應的間隙鎖: uid in (1, 2)

④ 鎖住uid=1對應的主鍵索引行鎖: id = [1, 3]

事務2 ：

① 鎖住zone_id=2對應的間隙鎖: zoneId in (1,2)

② 鎖住索引zone_id=2對應的主鍵索引行鎖id = [3,4]

③ 鎖住uid=2對應的間隙鎖: uid in (1, 2)

④ 鎖住uid=2對應的主鍵索引行鎖: id = [2, 4]

解決方案 ：創建聯合索引，使執行計劃只會用到一個索引。

測試表結構 :

場景復現操作 ：

解決辦法：盡量避免這種插入又回滾的場景。

避免死鎖的原則：

php中如何避免mysql數據庫死鎖

mysql一般不會死鎖，除非程序有問題。性能優先事務不優先的數據庫（設置）不要追求可靠性萬無一失。

網站性能問題主要是數據庫量大了以后，查詢掃描硬盤而產生的。其它性能不要太在意。編寫代碼的時候不要堅持性能原則，而是堅持可用性原則。初學者編寫代碼通常容易面向性能，但是一個項目的一個頁面幾百、幾千行代碼是很常見的。要面向可用性、可維護性、可讀性。這是項目原則。你看看java語言。對于網站，除了查詢掃描硬盤而產生的時間延遲，其它是不管的，只要不算有問題就可以。

連接方式是否為永久連接，在訪問量未達到高并發之前，還是非永久鏈接更好。非永久連接的資源消耗是不大于永久連接的，因為mysql是把連接權限緩存的，不會多次掃描硬盤，性能是可執行級別的而不是查找數據級別的。在訪問量達到高并發之后，性能問題的原因是多方面的，多環節的，是否為永久連接不是主要原因。

本文名稱：mysql怎么避免死鎖,mysql 避免死鎖
轉載注明：http://vcdvsql.cn/article18/hedjgp.html

成都網站建設公司_創新互聯，為您提供、小程序開發、網頁設計公司、網站維護、網站設計公司、網站制作

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯