詳解MySQL（InnoDB）如何處理死鎖

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

公司主營業(yè)務(wù)：做網(wǎng)站、成都網(wǎng)站建設(shè)、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)建站是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)建站推出華龍免費做網(wǎng)站回饋大家。

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

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

官方定義：

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

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

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

MySQL有兩種死鎖處理方式：

死鎖檢測 （默認開啟）

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

回滾

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

收集死鎖信息：

減少死鎖：

死鎖解決：

mysql 死鎖:如何解決mysql死鎖

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

mysql死鎖場景整理

本文死鎖場景皆為工作中遇到（或同事遇到）并解決的死鎖場景，寫這篇文章的目的是整理和分享，歡迎指正和補充，本文死鎖場景包括：

注 ：以下場景隔離級別均為默認的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)操作 ：

解決辦法：盡量避免這種插入又回滾的場景。

避免死鎖的原則：

mysql 發(fā)生死鎖問題請求幫助

目測不是因為存儲過程內(nèi)sql導(dǎo)致的死鎖:

因為存儲過程內(nèi)只有一條insert語句會持有鎖，也只持有一把鎖。所以不會導(dǎo)致死鎖。

引起死鎖肯定是由于資源共享沖突，事務(wù)是保證一個操作單元能執(zhí)行順利或失敗，保證數(shù)據(jù)的完整性的。

對于資源沖突肯定是需要鎖來控制，也就是使用數(shù)據(jù)的隔離機制和同步鎖來控制的，數(shù)據(jù)庫的隔離機制修改影響會比較大，所以建議在dao層使用同步或者加鎖來防止deadlock

但是可能會影響部分性能

mysql 死鎖排查

一、show ENGINE INNODB status

查看死鎖位置，分析。

二、

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

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

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