1.查看表被鎖狀態(tài)
創(chuàng)新互聯(lián)公司專注于企業(yè)成都全網(wǎng)營銷推廣、網(wǎng)站重做改版、湘潭網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5開發(fā)、商城網(wǎng)站定制開發(fā)、集團公司官網(wǎng)建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為湘潭等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
2.查看造成死鎖的sql語句
3.查詢進程
4.解鎖(刪除進程)
5.查看正在鎖的事物? (8.0以下版本)
6.查看等待鎖的事物?(8.0以下版本)
本文死鎖場景皆為工作中遇到（或同事遇到）并解決的死鎖場景，寫這篇文章的目的是整理和分享，歡迎指正和補充，本文死鎖場景包括：
注 ：以下場景隔離級別均為默認(rèn)的Repeatable Read；
前提 ：表 t_user 的 uid 字段創(chuàng)建了唯一索引，并擁有可更新字段age。
場景復(fù)現(xiàn) ：
相應(yīng)業(yè)務(wù)案例和解決方案 ：
該場景常見于事務(wù)中存在for循環(huán)更新某條記錄的情況，死鎖日志顯示 lock_mode X locks rec but not gap waiting （即行鎖而非間隙鎖），解決方案：
表結(jié)構(gòu) :
場景復(fù)現(xiàn) ：
首先查詢表中目前存在的記錄：
執(zhí)行兩個事務(wù)的操作：
死鎖原因分析 ：
解決方案 ：
t_user結(jié)構(gòu)改造為：
場景復(fù)現(xiàn)操作（幾率不高） ：
假設(shè)存在以下數(shù)據(jù) ：
死鎖分析 ：
事務(wù)1 ：
① 鎖住zone_id=1對應(yīng)的間隙鎖: zoneId in (1,2)
② 鎖住索引zone_id=1對應(yīng)的主鍵索引行鎖id = [1,2]
③ 鎖住uid=1對應(yīng)的間隙鎖: uid in (1, 2)
④ 鎖住uid=1對應(yīng)的主鍵索引行鎖: id = [1, 3]
事務(wù)2 ：
① 鎖住zone_id=2對應(yīng)的間隙鎖: zoneId in (1,2)
② 鎖住索引zone_id=2對應(yīng)的主鍵索引行鎖id = [3,4]
③ 鎖住uid=2對應(yīng)的間隙鎖: uid in (1, 2)
④ 鎖住uid=2對應(yīng)的主鍵索引行鎖: id = [2, 4]
解決方案 ：創(chuàng)建聯(lián)合索引，使執(zhí)行計劃只會用到一個索引。
測試表結(jié)構(gòu) :
場景復(fù)現(xiàn)操作 ：
解決辦法：盡量避免這種插入又回滾的場景。
避免死鎖的原則：
多線程開啟事務(wù)處理。每個事務(wù)有多個update操作和一個insert操作（都在同一張表）。
默認(rèn)隔離級別：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ù)常識考慮，我每個線程（事務(wù)）更新的數(shù)據(jù)都不沖突，為什么會產(chǎn)生死鎖？
帶著這個問題，打印mysql最近一次的死鎖信息
show engine innodb status
顯示如下
發(fā)現(xiàn)事務(wù)1在等待一個鎖
事務(wù)2也在等待一個鎖
而且事物2持有了事物1需要的鎖
關(guān)于鎖的描述，出現(xiàn)了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關(guān)于mysql的鎖相關(guān)的知識儲備還不夠。那就開始調(diào)查mysql的鎖相關(guān)知識。
通過搜索引擎，
鎖的持有兼容程度如下表
那么再回到死鎖日志，可以知道 :
事務(wù)1正在獲取插入意向鎖
事務(wù)2正在獲取插入意向鎖，持有排他gap鎖
再看我們上面的鎖兼容表格，可以知道， gap lock和insert intention lock是不兼容的
那么就可以推斷出： 事務(wù)1持有g(shù)ap lock，等待事務(wù)2的insert intention lock釋放；事務(wù)2持有g(shù)ap lock，等待事務(wù)1的insert intention lock釋放，從而導(dǎo)致死鎖。
那么新的問題就來了，事務(wù)1的intention lock 為什么會和事務(wù)2的gap lock 有交集，或者說，事務(wù)1要插入的數(shù)據(jù)的位置為什么會被事務(wù)2給鎖?。?/p>
讓我回顧一下gap lock的定義：
間隙鎖，鎖定一個范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務(wù)的兩次當(dāng)前讀，出現(xiàn)幻讀的情況
那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關(guān)的知識儲備還不夠。那就開始調(diào)查。
調(diào)查后發(fā)現(xiàn)，當(dāng)當(dāng)前索引是一個 普通索引 的時候，會加一個gap lock來防止幻讀， 此gap lock 會鎖住一個左開右閉的區(qū)間。 假設(shè)索引為xx_idx（xx_id），數(shù)據(jù)分布為1,4,6,8,12，當(dāng)更新xx_id=9的時候，這個時候gap lock的鎖定記錄區(qū)間就是(8，12]，也就是鎖住了xxid in (9,10,11,12)的數(shù)據(jù)，當(dāng)有其他事務(wù)要插入xxid in (9,10,11,12)的數(shù)據(jù)時，就會處于等待獲取鎖的狀態(tài)。
ps：當(dāng)前索引不是普通索引，而且是唯一索引等其他情況，請參考下面資料
MySQL 加鎖處理分析
回到我自己的案例中，重新屢一下事務(wù)1的執(zhí)行過程：
因為普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的關(guān)系 這段sql會獲取一個gap lock，范圍(2,11111]
這段sql會獲取一個insert intention lock （waiting）
再看事務(wù)2的執(zhí)行過程
因為普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的關(guān)系 這段sql也會獲取一個gap lock，范圍也是(2,11111]（根據(jù)前面的知識，gap lock之間會互相兼容，可以一起持有鎖的）
這段sql也會獲取一個insert intention lock （waiting）
看到這里，基本也就破案了。因為普通索引的關(guān)系，事務(wù)1和事務(wù)2的gap lock的覆蓋范圍太廣，導(dǎo)致其他事務(wù)無法插入數(shù)據(jù)。
重新梳理一下：
所以從結(jié)果來看，一堆事務(wù)被回滾，只有10007數(shù)據(jù)被更新成功
gap lock 導(dǎo)致了并發(fā)處理的死鎖
在mysql默認(rèn)的事務(wù)隔離級別（repeatable read）下，無法避免這種情況。只能把并發(fā)處理改成同步處理?；蛘邚臉I(yè)務(wù)層面做處理。
共享鎖、排他鎖、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
可直接在mysql命令行執(zhí)行:show engine innodb status\G; 查看造成死鎖的sql語句,分析索引情況,然后優(yōu)化sql然后show processlist; 另外可以打開慢查詢?nèi)罩?linux下打開需在...
重慶分公司
重慶分公司
