官方定義如下：兩個(gè)事務(wù)都持有對(duì)方需要的鎖，并且在等待對(duì)方釋放，并且雙方都不會(huì)釋放自己的鎖。
從化ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書未來市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！
這個(gè)就好比你有一個(gè)人質(zhì)，對(duì)方有一個(gè)人質(zhì)，你們倆去談判說換人。你讓對(duì)面放人，對(duì)面讓你放人。
看到這里，也許你會(huì)有這樣的疑問，事務(wù)和談判不一樣，為什么事務(wù)不能使用完鎖之后立馬釋放呢？居然還要操作完了之后一直持有鎖？這就涉及到 MySQL 的并發(fā)控制了。
MySQL的并發(fā)控制有兩種方式，一個(gè)是 MVCC，一個(gè)是兩階段鎖協(xié)議。那么為什么要并發(fā)控制呢？是因?yàn)槎鄠€(gè)用戶同時(shí)操作 MySQL 的時(shí)候，為了提高并發(fā)性能并且要求如同多個(gè)用戶的請(qǐng)求過來之后如同串行執(zhí)行的一樣（ 可串行化調(diào)度 ）。具體的并發(fā)控制這里不再展開。咱們繼續(xù)深入討論兩階段鎖協(xié)議。
官方定義：
對(duì)應(yīng)到 MySQL 上分為兩個(gè)階段：
就是說呢，只有遵循兩段鎖協(xié)議，才能實(shí)現(xiàn) 可串行化調(diào)度 。
但是兩階段鎖協(xié)議不要求事務(wù)必須一次將所有需要使用的數(shù)據(jù)加鎖，并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會(huì)形成死鎖。
MySQL有兩種死鎖處理方式：
由于性能原因，一般都是使用死鎖檢測(cè)來進(jìn)行處理死鎖。
死鎖檢測(cè)的原理是構(gòu)建一個(gè)以事務(wù)為頂點(diǎn)、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
檢測(cè)到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
MySQL如何處理死鎖
鎖是需要事務(wù)結(jié)束后才釋放的。
一個(gè)是 MVCC，一個(gè)是兩階段鎖協(xié)議。
為什么要并發(fā)控制呢？是因?yàn)槎鄠€(gè)用戶同時(shí)操作 MySQL 的時(shí)候，為了提高并發(fā)性能并且要求如同多個(gè)用戶的請(qǐng)求過來之后如同串行執(zhí)行的一樣（為了解決臟讀、不可重復(fù)讀、幻讀）
官方定義：
兩階段鎖協(xié)議是指所有事務(wù)必須分兩個(gè)階段對(duì)數(shù)據(jù)加鎖和解鎖，在對(duì)任何數(shù)據(jù)進(jìn)行讀、寫操作之前，事務(wù)首先要獲得對(duì)該數(shù)據(jù)的封鎖；在釋放一個(gè)封鎖之后，事務(wù)不再申請(qǐng)和獲得任何其他封鎖。
對(duì)應(yīng)到 MySQL 上分為兩個(gè)階段：
但是兩階段鎖協(xié)議不要求事務(wù)必須一次將所有需要使用的數(shù)據(jù)加鎖（innodb在需要的索引列數(shù)據(jù)才鎖行），并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會(huì)形成死鎖。
MySQL有兩種死鎖處理方式：
死鎖檢測(cè) （默認(rèn)開啟）
死鎖檢測(cè)的原理是構(gòu)建一個(gè)以事務(wù)為頂點(diǎn)、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
回滾
檢測(cè)到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
收集死鎖信息：
減少死鎖：
死鎖解決：
多線程開啟事務(wù)處理。每個(gè)事務(wù)有多個(gè)update操作和一個(gè)insert操作（都在同一張表）。
默認(rèn)隔離級(jí)別：Repeatable Read
只有hotel_id=2和hotel_id=11111的數(shù)據(jù)
邏輯刪除原有數(shù)據(jù)
插入新的數(shù)據(jù)
根據(jù)現(xiàn)有數(shù)據(jù)情況，update的時(shí)候沒有數(shù)據(jù)被更新
報(bào)了非常多一樣的錯(cuò)
發(fā)現(xiàn)居然有死鎖。
根據(jù)常識(shí)考慮，我每個(gè)線程（事務(wù)）更新的數(shù)據(jù)都不沖突，為什么會(huì)產(chǎn)生死鎖？
帶著這個(gè)問題，打印mysql最近一次的死鎖信息
show engine innodb status
顯示如下
發(fā)現(xiàn)事務(wù)1在等待一個(gè)鎖
事務(wù)2也在等待一個(gè)鎖
而且事物2持有了事物1需要的鎖
關(guān)于鎖的描述，出現(xiàn)了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關(guān)于mysql的鎖相關(guān)的知識(shí)儲(chǔ)備還不夠。那就開始調(diào)查mysql的鎖相關(guān)知識(shí)。
通過搜索引擎，
鎖的持有兼容程度如下表
那么再回到死鎖日志，可以知道 :
事務(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 為什么會(huì)和事務(wù)2的gap lock 有交集，或者說，事務(wù)1要插入的數(shù)據(jù)的位置為什么會(huì)被事務(wù)2給鎖住？
讓我回顧一下gap lock的定義：
間隙鎖，鎖定一個(gè)范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務(wù)的兩次當(dāng)前讀，出現(xiàn)幻讀的情況
那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關(guān)的知識(shí)儲(chǔ)備還不夠。那就開始調(diào)查。
調(diào)查后發(fā)現(xiàn)，當(dāng)當(dāng)前索引是一個(gè) 普通索引 的時(shí)候，會(huì)加一個(gè)gap lock來防止幻讀， 此gap lock 會(huì)鎖住一個(gè)左開右閉的區(qū)間。 假設(shè)索引為xx_idx（xx_id），數(shù)據(jù)分布為1,4,6,8,12，當(dāng)更新xx_id=9的時(shí)候，這個(gè)時(shí)候gap lock的鎖定記錄區(qū)間就是(8，12]，也就是鎖住了xxid in (9,10,11,12)的數(shù)據(jù)，當(dāng)有其他事務(wù)要插入xxid in (9,10,11,12)的數(shù)據(jù)時(shí)，就會(huì)處于等待獲取鎖的狀態(tài)。
ps：當(dāng)前索引不是普通索引，而且是唯一索引等其他情況，請(qǐng)參考下面資料
MySQL 加鎖處理分析
回到我自己的案例中，重新屢一下事務(wù)1的執(zhí)行過程：
因?yàn)槠胀ㄋ饕?/p>
KEY hotel_date_idx ( hotel_id , rate_date )
的關(guān)系 這段sql會(huì)獲取一個(gè)gap lock，范圍(2,11111]
這段sql會(huì)獲取一個(gè)insert intention lock （waiting）
再看事務(wù)2的執(zhí)行過程
因?yàn)槠胀ㄋ饕?/p>
KEY hotel_date_idx ( hotel_id , rate_date )
的關(guān)系 這段sql也會(huì)獲取一個(gè)gap lock，范圍也是(2,11111]（根據(jù)前面的知識(shí)，gap lock之間會(huì)互相兼容，可以一起持有鎖的）
這段sql也會(huì)獲取一個(gè)insert intention lock （waiting）
看到這里，基本也就破案了。因?yàn)槠胀ㄋ饕年P(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ù)隔離級(jí)別（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下打開需在...
一、show ENGINE INNODB status
查看死鎖位置，分析。
二、
首先解決死鎖可以從死鎖發(fā)生的條件入手，最容易解決的就是更改獲取資源的順序；
其次是避免長事務(wù)，讓事務(wù)執(zhí)行的時(shí)間盡可能少，讓事務(wù)的覆蓋范圍盡可能小，長事務(wù)會(huì)導(dǎo)致并發(fā)度降低，且會(huì)有更多的SQL查 詢延遲；
給整個(gè)方法加事務(wù)是否是必須的？可以不加事務(wù)的盡量不加。
mysql數(shù)據(jù)庫死鎖解決方法如下：
1、對(duì)于按鈕等控件，點(diǎn)擊后使其立刻失效，不讓用戶重復(fù)點(diǎn)擊，避免對(duì)同時(shí)對(duì)同一條記錄操作。
2、使用樂觀鎖進(jìn)行控制。樂觀鎖大多是基于數(shù)據(jù)版本（Version）記錄機(jī)制實(shí)現(xiàn)。即為數(shù)據(jù)增加一個(gè)版本標(biāo)識(shí)，在基于數(shù)據(jù)庫表的版本解決方案中，一般是 通過為數(shù)據(jù)庫表增加一個(gè)“version”字段來實(shí)現(xiàn)。讀取出數(shù)據(jù)時(shí)，將此版本號(hào)一同讀出，之后更新時(shí)，對(duì)此版本號(hào)加一。此時(shí)，將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù) 據(jù)庫表對(duì)應(yīng)記錄的當(dāng)前版本信息進(jìn)行比對(duì)，如果提交的數(shù)據(jù)版本號(hào)大于數(shù)據(jù)庫表當(dāng)前版本號(hào)，則予以更新，否則認(rèn)為是過期數(shù)據(jù)。樂觀鎖機(jī)制避免了長事務(wù)中的數(shù)據(jù) 庫加鎖開銷（用戶A和用戶B操作過程中，都沒有對(duì)數(shù)據(jù)庫數(shù)據(jù)加鎖），大大提升了大并發(fā)量下的系統(tǒng)整體性能表現(xiàn)。Hibernate 在其數(shù)據(jù)訪問引擎中內(nèi)置了樂觀鎖實(shí)現(xiàn)。需要注意的是，由于樂觀鎖機(jī)制是在系統(tǒng)中實(shí)現(xiàn)，來自外部系統(tǒng)的用戶更新操作不受系統(tǒng)的控制，因此可能會(huì)造 成臟數(shù)據(jù)被更新到數(shù)據(jù)庫中。
重慶分公司
重慶分公司
