數(shù)據(jù)越來越和我們的生活離不開，數(shù)據(jù)在生命周期的各個階段有著不同的痛點和需求以及特殊場景。

成都創(chuàng)新互聯(lián)專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、安國網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5頁面制作、商城網(wǎng)站建設(shè)、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為安國等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

CURD是數(shù)據(jù)的四大基本需求:寫入，更新，讀取，刪除.

今天，來談一談死鎖問題

死鎖是高并發(fā)下MySQL不可回避的一個問題。

這句話可以引申四個問題:

1.什么是死鎖？

2.MySQL什么時候會檢測死鎖？

3.數(shù)據(jù)庫系統(tǒng)如何處理死鎖？

4.有哪些典型的高并發(fā)死鎖場景？

1.我們先來看看什么是死鎖。

在《數(shù)據(jù)庫系統(tǒng)實現(xiàn)》第八章第二節(jié)這樣定義死鎖

并發(fā)執(zhí)行的事務(wù)由于競爭資源而到達一個存在死鎖的狀態(tài):若干事務(wù)的每一個事務(wù)都在等待被其他事務(wù)占用的資源，因而每個事務(wù)都不能取得進展。

這個描述貌似很拗口，我們舉兩個例子來形象化認識一下:

1.兩位木匠釘?shù)匕?，一位只握一把斧頭，而另一位沒有榔頭，卻有釘子

2.堵車現(xiàn)象

看完死鎖的定義描述和形象化認識，那對于MySQL，什么時候會進行死鎖檢測？

2.MySQL的死鎖檢測和回滾

這里談?wù)揗ySQL的死鎖檢測，目前僅討論InnoDB的處理，暫不涉及MyRocks的死鎖檢測處理。

當(dāng)InnoDB事務(wù)嘗試獲取(請求)加一個鎖，并且需要等待時，InnoDB會進行死鎖檢測.

正常的流程如下:

1.InnoDB的初始化一個事務(wù)，當(dāng)事務(wù)嘗試獲?。ㄕ埱螅┘右粋€鎖，并且需要等待時(wait_lock)，innodb會開始進行死鎖檢測(deadlock_mark)

2.進入到lock_deadlock_check_and_resolve ，名字很明顯了，要檢測死鎖和解決死鎖

3.檢測死鎖過程中，也是有計數(shù)器來進行限制的

4.死鎖檢測的邏輯之一是等待圖的處理過程，如果通過鎖的信息和事務(wù)等待鏈構(gòu)造出一個圖，如果圖中出現(xiàn)回路，就認為發(fā)生了死鎖。

5.死鎖的回滾，內(nèi)部代碼的處理邏輯之一是比較undo的數(shù)量

3.數(shù)據(jù)庫系統(tǒng)如何處理死鎖

我們回頭繼續(xù)看《數(shù)據(jù)庫系統(tǒng)實現(xiàn)》里面提到的死鎖處理

1.超時死鎖檢測:當(dāng)存在死鎖時，想所有事務(wù)都能同時繼續(xù)執(zhí)行通常是不可能的，因此，至少一個事務(wù)必須中止并重新開始。超時是最直接的辦法，對超出活躍時間的事務(wù)進行限制和回滾

2.等待圖：等待圖的實現(xiàn)，是可以表明哪些事務(wù)在等待其他事務(wù)持有的鎖，可以在數(shù)據(jù)庫的死鎖檢測里面加上這個機制來進行檢測是否有環(huán)的形成。

3.通過元素排序預(yù)防死鎖:這個想法很美好，但現(xiàn)實很殘酷,通常都是發(fā)現(xiàn)死鎖后才去想辦法解決死鎖的原因

4.通過時間戳檢測死鎖:對每個事務(wù)都分配一個時間戳，根據(jù)時間戳來進行回滾策略。

這里貼一下等待圖的示例

4.有哪些典型的高并發(fā)死鎖場景？

1.秒殺場景，每個秒殺都是針對同一行的活躍事務(wù)，源源不斷的事務(wù)發(fā)現(xiàn)自己加鎖的那一行已經(jīng)被人鎖了，這時候InnoDB會進入一個蛋疼的沒必要的死鎖檢測，后續(xù)給大家講講怎么解決 

2.使用二級索引去高并發(fā)更新二級索引記錄（很拗口吧？），MySQL的索引計劃不是100%準確的，我手上有case在并發(fā)更新不同記錄的時候，因為索引計劃走錯了，導(dǎo)致某一個事務(wù)用了二級索引讀記錄，另外一個事務(wù)用主鍵來讀記錄，進而產(chǎn)生了死鎖，這個案例后續(xù)也會整理出來。

最后 MySQL的源碼如何進行死鎖檢測和處理？

這個問題是后續(xù)的關(guān)鍵，但沒整理完，先歇一歇...

建議先讀一讀上一篇《InnoDB事務(wù)結(jié)構(gòu)體代碼變量列表》，因為死鎖是在活躍事務(wù)等待鎖的情況下才會去檢測，要先去了解InnoDB事務(wù)結(jié)構(gòu)體的trx_lock_t