mysql出現(xiàn)死鎖怎么辦 mysql死鎖會自動釋放嗎
mysql解決死鎖問題
官方定義如下：兩個事務都持有對方需要的鎖，并且在等待對方釋放，并且雙方都不會釋放自己的鎖。
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供磴口網(wǎng)站建設、磴口做網(wǎng)站、磴口網(wǎng)站設計、磴口網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、磴口企業(yè)網(wǎng)站模板建站服務，十年磴口做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。
這個就好比你有一個人質(zhì)，對方有一個人質(zhì)，你們倆去談判說換人。你讓對面放人，對面讓你放人。
看到這里，也許你會有這樣的疑問，事務和談判不一樣，為什么事務不能使用完鎖之后立馬釋放呢？居然還要操作完了之后一直持有鎖？這就涉及到 MySQL 的并發(fā)控制了。
MySQL的并發(fā)控制有兩種方式，一個是 MVCC，一個是兩階段鎖協(xié)議。那么為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（ 可串行化調(diào)度 ）。具體的并發(fā)控制這里不再展開。咱們繼續(xù)深入討論兩階段鎖協(xié)議。
官方定義：
對應到 MySQL 上分為兩個階段：
就是說呢，只有遵循兩段鎖協(xié)議，才能實現(xiàn) 可串行化調(diào)度 。
但是兩階段鎖協(xié)議不要求事務必須一次將所有需要使用的數(shù)據(jù)加鎖，并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會形成死鎖。
MySQL有兩種死鎖處理方式：
由于性能原因，一般都是使用死鎖檢測來進行處理死鎖。
死鎖檢測的原理是構(gòu)建一個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
檢測到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
MySQL如何處理死鎖
mysql發(fā)生死鎖怎么解決
可直接在mysql命令行執(zhí)行:show engine innodb status\G; 查看造成死鎖的sql語句,分析索引情況,然后優(yōu)化sql然后show processlist; 另外可以打開慢查詢?nèi)罩?linux下打開需在...
詳解MySQL（InnoDB）如何處理死鎖
鎖是需要事務結(jié)束后才釋放的。
一個是 MVCC，一個是兩階段鎖協(xié)議。
為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（為了解決臟讀、不可重復讀、幻讀）
官方定義：
兩階段鎖協(xié)議是指所有事務必須分兩個階段對數(shù)據(jù)加鎖和解鎖，在對任何數(shù)據(jù)進行讀、寫操作之前，事務首先要獲得對該數(shù)據(jù)的封鎖；在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖。
對應到 MySQL 上分為兩個階段：
但是兩階段鎖協(xié)議不要求事務必須一次將所有需要使用的數(shù)據(jù)加鎖（innodb在需要的索引列數(shù)據(jù)才鎖行），并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會形成死鎖。
MySQL有兩種死鎖處理方式：
死鎖檢測 （默認開啟）
死鎖檢測的原理是構(gòu)建一個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
回滾
檢測到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
收集死鎖信息：
減少死鎖：
死鎖解決：
解決一次mysql死鎖問題
多線程開啟事務處理。每個事務有多個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需要的鎖
關(guān)于鎖的描述，出現(xiàn)了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關(guān)于mysql的鎖相關(guān)的知識儲備還不夠。那就開始調(diào)查mysql的鎖相關(guān)知識。
通過搜索引擎，
鎖的持有兼容程度如下表
那么再回到死鎖日志，可以知道 :
事務1正在獲取插入意向鎖
事務2正在獲取插入意向鎖，持有排他gap鎖
再看我們上面的鎖兼容表格，可以知道， gap lock和insert intention lock是不兼容的
那么就可以推斷出： 事務1持有g(shù)ap lock，等待事務2的insert intention lock釋放；事務2持有g(shù)ap lock，等待事務1的insert intention lock釋放，從而導致死鎖。
那么新的問題就來了，事務1的intention lock 為什么會和事務2的gap lock 有交集，或者說，事務1要插入的數(shù)據(jù)的位置為什么會被事務2給鎖?。?/p>
讓我回顧一下gap lock的定義：
間隙鎖，鎖定一個范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務的兩次當前讀，出現(xiàn)幻讀的情況
那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關(guā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 )
的關(guān)系 這段sql會獲取一個gap lock，范圍(2,11111]
這段sql會獲取一個insert intention lock （waiting）
再看事務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)系，事務1和事務2的gap lock的覆蓋范圍太廣，導致其他事務無法插入數(shù)據(jù)。
重新梳理一下：
所以從結(jié)果來看，一堆事務被回滾，只有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
分享文章：mysql出現(xiàn)死鎖怎么辦 mysql死鎖會自動釋放嗎
URL標題：http://muchs.cn/article48/dojhpep.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設、ChatGPT、電子商務、軟件開發(fā)、品牌網(wǎng)站制作、外貿(mào)網(wǎng)站建設
聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)
