本文死鎖場景皆為工作中遇到（或同事遇到）并解決的死鎖場景，寫這篇文章的目的是整理和分享，歡迎指正和補充，本文死鎖場景包括：
成都創(chuàng)新互聯(lián)公司成都企業(yè)網(wǎng)站建設服務，提供成都網(wǎng)站設計、成都做網(wǎng)站網(wǎng)站開發(fā),網(wǎng)站定制,建網(wǎng)站,網(wǎng)站搭建,網(wǎng)站設計,成都響應式網(wǎng)站建設公司,網(wǎng)頁設計師打造企業(yè)風格網(wǎng)站,提供周到的售前咨詢和貼心的售后服務。歡迎咨詢做網(wǎng)站需要多少錢:18980820575
注 ：以下場景隔離級別均為默認的Repeatable Read；
前提 ：表 t_user 的 uid 字段創(chuàng)建了唯一索引，并擁有可更新字段age。
場景復現(xiàn) ：
相應業(yè)務案例和解決方案 ：
該場景常見于事務中存在for循環(huán)更新某條記錄的情況，死鎖日志顯示 lock_mode X locks rec but not gap waiting （即行鎖而非間隙鎖），解決方案：
表結構 :
場景復現(xiàn) ：
首先查詢表中目前存在的記錄：
執(zhí)行兩個事務的操作：
死鎖原因分析 ：
解決方案 ：
t_user結構改造為：
場景復現(xiàn)操作（幾率不高） ：
假設存在以下數(shù)據(jù) ：
死鎖分析 ：
事務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]
解決方案 ：創(chuàng)建聯(lián)合索引，使執(zhí)行計劃只會用到一個索引。
測試表結構 :
場景復現(xiàn)操作 ：
解決辦法：盡量避免這種插入又回滾的場景。
避免死鎖的原則：
多線程開啟事務處理。每個事務有多個update操作和一個insert操作（都在同一張表）。
默認隔離級別：Repeatable Read
只有hotel_id=2和hotel_id=11111的數(shù)據(jù)
邏輯刪除原有數(shù)據(jù)
插入新的數(shù)據(jù)
根據(jù)現(xiàn)有數(shù)據(jù)情況，update的時候沒有數(shù)據(jù)被更新
報了非常多一樣的錯
發(fā)現(xiàn)居然有死鎖。
根據(jù)常識考慮，我每個線程（事務）更新的數(shù)據(jù)都不沖突，為什么會產(chǎn)生死鎖？
帶著這個問題，打印mysql最近一次的死鎖信息
show engine innodb status
顯示如下
發(fā)現(xiàn)事務1在等待一個鎖
事務2也在等待一個鎖
而且事物2持有了事物1需要的鎖
關于鎖的描述，出現(xiàn)了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關于mysql的鎖相關的知識儲備還不夠。那就開始調(diào)查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要插入的數(shù)據(jù)的位置為什么會被事務2給鎖住？
讓我回顧一下gap lock的定義：
間隙鎖，鎖定一個范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務的兩次當前讀，出現(xiàn)幻讀的情況
那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關的知識儲備還不夠。那就開始調(diào)查。
調(diào)查后發(fā)現(xiàn)，當當前索引是一個 普通索引 的時候，會加一個gap lock來防止幻讀， 此gap lock 會鎖住一個左開右閉的區(qū)間。 假設索引為xx_idx（xx_id），數(shù)據(jù)分布為1,4,6,8,12，當更新xx_id=9的時候，這個時候gap lock的鎖定記錄區(qū)間就是(8，12]，也就是鎖住了xxid in (9,10,11,12)的數(shù)據(jù)，當有其他事務要插入xxid in (9,10,11,12)的數(shù)據(jù)時，就會處于等待獲取鎖的狀態(tài)。
ps：當前索引不是普通索引，而且是唯一索引等其他情況，請參考下面資料
MySQL 加鎖處理分析
回到我自己的案例中，重新屢一下事務1的執(zhí)行過程：
因為普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的關系 這段sql會獲取一個gap lock，范圍(2,11111]
這段sql會獲取一個insert intention lock （waiting）
再看事務2的執(zhí)行過程
因為普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的關系 這段sql也會獲取一個gap lock，范圍也是(2,11111]（根據(jù)前面的知識，gap lock之間會互相兼容，可以一起持有鎖的）
這段sql也會獲取一個insert intention lock （waiting）
看到這里，基本也就破案了。因為普通索引的關系，事務1和事務2的gap lock的覆蓋范圍太廣，導致其他事務無法插入數(shù)據(jù)。
重新梳理一下：
所以從結果來看，一堆事務被回滾，只有10007數(shù)據(jù)被更新成功
gap lock 導致了并發(fā)處理的死鎖
在mysql默認的事務隔離級別（repeatable read）下，無法避免這種情況。只能把并發(fā)處理改成同步處理?；蛘邚臉I(yè)務層面做處理。
共享鎖、排他鎖、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
鎖是需要事務結束后才釋放的。
一個是 MVCC，一個是兩階段鎖協(xié)議。
為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（為了解決臟讀、不可重復讀、幻讀）
官方定義：
兩階段鎖協(xié)議是指所有事務必須分兩個階段對數(shù)據(jù)加鎖和解鎖，在對任何數(shù)據(jù)進行讀、寫操作之前，事務首先要獲得對該數(shù)據(jù)的封鎖；在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖。
對應到 MySQL 上分為兩個階段：
但是兩階段鎖協(xié)議不要求事務必須一次將所有需要使用的數(shù)據(jù)加鎖（innodb在需要的索引列數(shù)據(jù)才鎖行），并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會形成死鎖。
MySQL有兩種死鎖處理方式：
死鎖檢測 （默認開啟）
死鎖檢測的原理是構建一個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
回滾
檢測到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
收集死鎖信息：
減少死鎖：
死鎖解決：
mysql數(shù)據(jù)庫死鎖解決方法如下：
1、對于按鈕等控件，點擊后使其立刻失效，不讓用戶重復點擊，避免對同時對同一條記錄操作。
2、使用樂觀鎖進行控制。樂觀鎖大多是基于數(shù)據(jù)版本（Version）記錄機制實現(xiàn)。即為數(shù)據(jù)增加一個版本標識，在基于數(shù)據(jù)庫表的版本解決方案中，一般是 通過為數(shù)據(jù)庫表增加一個“version”字段來實現(xiàn)。讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù) 據(jù)庫表對應記錄的當前版本信息進行比對，如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫表當前版本號，則予以更新，否則認為是過期數(shù)據(jù)。樂觀鎖機制避免了長事務中的數(shù)據(jù) 庫加鎖開銷（用戶A和用戶B操作過程中，都沒有對數(shù)據(jù)庫數(shù)據(jù)加鎖），大大提升了大并發(fā)量下的系統(tǒng)整體性能表現(xiàn)。Hibernate 在其數(shù)據(jù)訪問引擎中內(nèi)置了樂觀鎖實現(xiàn)。需要注意的是，由于樂觀鎖機制是在系統(tǒng)中實現(xiàn)，來自外部系統(tǒng)的用戶更新操作不受系統(tǒng)的控制，因此可能會造 成臟數(shù)據(jù)被更新到數(shù)據(jù)庫中。
可直接在mysql命令行執(zhí)行:show engine innodb status\G; 查看造成死鎖的sql語句,分析索引情況,然后優(yōu)化sql然后show processlist; 另外可以打開慢查詢?nèi)罩?linux下打開需在...
重慶分公司
重慶分公司
