建站
咨詢
售后
建站咨詢
新聞中心
詳解MySQL（InnoDB）如何處理死鎖
鎖是需要事務(wù)結(jié)束后才釋放的。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比蔚縣網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式蔚縣網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋蔚縣地區(qū)。費(fèi)用合理售后完善，十載實(shí)體公司更值得信賴。
一個(gè)是 MVCC，一個(gè)是兩階段鎖協(xié)議。
為什么要并發(fā)控制呢？是因?yàn)槎鄠€(gè)用戶同時(shí)操作 MySQL 的時(shí)候，為了提高并發(fā)性能并且要求如同多個(gè)用戶的請(qǐng)求過(guò)來(lái)之后如同串行執(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ù)才鎖行），并且在加鎖階段沒(méi)有順序要求，所以這種并發(fā)控制方式會(huì)形成死鎖。
MySQL有兩種死鎖處理方式：
死鎖檢測(cè) （默認(rèn)開啟）
死鎖檢測(cè)的原理是構(gòu)建一個(gè)以事務(wù)為頂點(diǎn)、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
回滾
檢測(cè)到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來(lái)判斷。
收集死鎖信息：
減少死鎖：
死鎖解決：
mysql解決死鎖問(wèn)題
官方定義如下：兩個(gè)事務(wù)都持有對(duì)方需要的鎖，并且在等待對(duì)方釋放，并且雙方都不會(huì)釋放自己的鎖。
這個(gè)就好比你有一個(gè)人質(zhì)，對(duì)方有一個(gè)人質(zhì)，你們倆去談判說(shuō)換人。你讓對(duì)面放人，對(duì)面讓你放人。
看到這里，也許你會(huì)有這樣的疑問(wèn)，事務(wù)和談判不一樣，為什么事務(wù)不能使用完鎖之后立馬釋放呢？居然還要操作完了之后一直持有鎖？這就涉及到 MySQL 的并發(fā)控制了。
MySQL的并發(fā)控制有兩種方式，一個(gè)是 MVCC，一個(gè)是兩階段鎖協(xié)議。那么為什么要并發(fā)控制呢？是因?yàn)槎鄠€(gè)用戶同時(shí)操作 MySQL 的時(shí)候，為了提高并發(fā)性能并且要求如同多個(gè)用戶的請(qǐng)求過(guò)來(lái)之后如同串行執(zhí)行的一樣（ 可串行化調(diào)度 ）。具體的并發(fā)控制這里不再展開。咱們繼續(xù)深入討論兩階段鎖協(xié)議。
官方定義：
對(duì)應(yīng)到 MySQL 上分為兩個(gè)階段：
就是說(shuō)呢，只有遵循兩段鎖協(xié)議，才能實(shí)現(xiàn) 可串行化調(diào)度 。
但是兩階段鎖協(xié)議不要求事務(wù)必須一次將所有需要使用的數(shù)據(jù)加鎖，并且在加鎖階段沒(méi)有順序要求，所以這種并發(fā)控制方式會(huì)形成死鎖。
MySQL有兩種死鎖處理方式：
由于性能原因，一般都是使用死鎖檢測(cè)來(lái)進(jìn)行處理死鎖。
死鎖檢測(cè)的原理是構(gòu)建一個(gè)以事務(wù)為頂點(diǎn)、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
檢測(cè)到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來(lái)判斷。
MySQL如何處理死鎖
巧用MySQL InnoDB引擎鎖機(jī)制解決死鎖問(wèn)題[2]
索引 KEY_TSKTASK_MONTIME (STATUS_ID MON_TIME)
分析 涉及的兩條語(yǔ)句應(yīng)該不會(huì)涉及相同的TSK_TASK記錄 那為什么會(huì)造成死鎖呢？
查詢MySQL官網(wǎng)文檔 發(fā)現(xiàn)這跟MySQL的索引機(jī)制有關(guān) MySQL的InnoDB引擎是行級(jí)鎖 我原來(lái)的理解是直接對(duì)記錄進(jìn)行鎖定 實(shí)際上并不是這樣的
要點(diǎn)如下:
不是對(duì)記錄進(jìn)行鎖定 而是對(duì)索引進(jìn)行鎖定
在UPDATE DELETE操作時(shí) MySQL不僅鎖定WHERE條件掃描過(guò)的所有索引記錄 而且會(huì)鎖定相鄰的鍵值 即所謂的next key locking
如語(yǔ)句UPDATE TSK_TASK SET UPDATE_TIME = NOW() WHERE ID 會(huì)鎖定所有主鍵大于等于 的所有記錄 在該語(yǔ)句完成之前 你就不能對(duì)主鍵等于 的記錄進(jìn)行操作
當(dāng)非簇索引(non cluster index)記錄被鎖定時(shí) 相關(guān)的簇索引(cluster index)記錄也需要被鎖定才能完成相應(yīng)的操作
再分析一下發(fā)生問(wèn)題的兩條SQL語(yǔ)句 就不難找到問(wèn)題所在了
當(dāng) update TSK_TASK set STATUS_ID= UPDATE_TIME=now () where STATUS_ID= and MON_TIME
假設(shè) update TSK_TASK set STATUS_ID= UPDATE_TIME=now () where ID in ( ) 幾乎同時(shí)執(zhí)行時(shí) 本語(yǔ)句首先鎖定簇索引(主鍵) 由于需要更新STATUS_ID的值 所以還需要鎖定KEY_TSKTASK_MONTIME 的某些索引記錄
這樣第一條語(yǔ)句鎖定了KEY_TSKTASK_MONTIME 的記錄 等待主鍵索引 而第二條語(yǔ)句則鎖定了主鍵索引記錄 而等待KEY_TSKTASK_MONTIME 的記錄 在此情況下 死鎖就產(chǎn)生了
筆者通過(guò)拆分第一條語(yǔ)句解決死鎖問(wèn)題
先查出符合條件的ID select ID from TSK_TASK where STATUS_ID= and MON_TIME date_sub(now() INTERVAL minute) 然后再更新狀態(tài) update TSK_TASK set STATUS_ID= where ID in (… )
至此 死鎖問(wèn)題徹底解決
lishixinzhi/Article/program/MySQL/201311/29601
網(wǎng)頁(yè)標(biāo)題：mysql死鎖怎么優(yōu)化 mysql解決死鎖的三種方法
本文鏈接：http://www.ef60e0e.cn/article/ddeisgd.html
