mysql怎么解決死鎖 mysql死鎖的處理方法

解決一次mysql死鎖問題

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

江北網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站設(shè)計等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)公司2013年至今到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。

默認(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給鎖??？

讓我回顧一下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（InnoDB）如何處理死鎖

鎖是需要事務(wù)結(jié)束后才釋放的。

一個是 MVCC，一個是兩階段鎖協(xié)議。

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

官方定義：

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

對應(yīng)到 MySQL 上分為兩個階段：

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

MySQL有兩種死鎖處理方式：

死鎖檢測 （默認(rèn)開啟）

死鎖檢測的原理是構(gòu)建一個以事務(wù)為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。

回滾

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

收集死鎖信息：

減少死鎖：

死鎖解決：

mysql 死鎖排查

一、show ENGINE INNODB status

查看死鎖位置，分析。

二、

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

其次是避免長事務(wù)，讓事務(wù)執(zhí)行的時間盡可能少，讓事務(wù)的覆蓋范圍盡可能小，長事務(wù)會導(dǎo)致并發(fā)度降低，且會有更多的SQL查 詢延遲；

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

死鎖怎么解決？

處理死鎖的思路如下：

預(yù)防死鎖：破壞四個必要條件中的一個或多個來預(yù)防死鎖。

避免死鎖：在資源動態(tài)分配的過程中，用某種方式防止系統(tǒng)進(jìn)入不安全的狀態(tài)。

檢測死鎖：運行時產(chǎn)生死鎖，及時發(fā)現(xiàn)思索，將程序解脫出來。

解除死鎖：發(fā)生死鎖后，撤銷進(jìn)程，回收資源，分配給正在阻塞狀態(tài)的進(jìn)程。

預(yù)防死鎖的辦法：

破壞請求和保持條件：

1、一次性的申請所有資源。之后不在申請資源，如果不滿足資源條件則得不到資源分配。

2、只獲得初期資源運行，之后將運行完的資源釋放，請求新的資源。

破壞不可搶占條件：當(dāng)一個進(jìn)程獲得某種不可搶占資源，提出新的資源申請，若不能滿足，則釋放所有資源，以后需要，再次重新申請。

破壞循環(huán)等待條件：對資源進(jìn)行排號，按照序號遞增的順序請求資源。若進(jìn)程獲得序號高的資源想要獲取序號低的資源，就需要先釋放序號高的資源。

擴(kuò)展資料

形成死鎖的四個必要條件：

（1） 互斥條件：一個資源每次只能被一個進(jìn)程使用。

（2） 請求與保持條件：一個進(jìn)程因請求資源而阻塞時，對已獲得的資源保持不放。

（3） 不剝奪條件:進(jìn)程已獲得的資源，在末使用完之前，不能強行剝奪。

（4） 循環(huán)等待條件:若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。

如果一組進(jìn)程中每一個進(jìn)程都在等待僅由該組進(jìn)程中的其他進(jìn)程才能引發(fā)的事件，那么該組進(jìn)程是死鎖的。

舉例來說：有兩個進(jìn)程A和B,A持有資源a等待b資源，B持有資源b等待a資源，兩個進(jìn)程都在等待另一個資源的同時不釋放資源，就形成死鎖。

mysql發(fā)生死鎖怎么解決

可直接在mysql命令行執(zhí)行:show engine innodb status\G; 查看造成死鎖的sql語句,分析索引情況,然后優(yōu)化sql然后show processlist; 另外可以打開慢查詢?nèi)罩?linux下打開需在...

網(wǎng)頁標(biāo)題：mysql怎么解決死鎖 mysql死鎖的處理方法
URL分享：http://muchs.cn/article18/hhejgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、網(wǎng)頁設(shè)計公司、手機(jī)網(wǎng)站建設(shè)、ChatGPT、電子商務(wù)、企業(yè)建站

廣告

聲明：本網(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)