面試官：你怎麼連MySQL死鎖產生緣由都不知道？

1、Mysql 鎖類型和加鎖分析

一、鎖類型介紹：

MySQL有三種鎖的級別：頁級、表級、行級。

• 表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的機率最高,併發度最低。

• 行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的機率最低,併發度也最高。

• 頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度通常

算法：

• next KeyLocks鎖，同時鎖住記錄(數據)，而且鎖住記錄前面的Gap

• Gap鎖，不鎖記錄，僅僅記錄前面的Gap

• Recordlock鎖（鎖數據，不鎖Gap）

• 因此其實 Next-KeyLocks=Gap鎖+ Recordlock鎖

二、加鎖分析：

http://hedengcheng.com/?p=771

2、死鎖產生緣由和示例

一、產生緣由：

所謂死鎖<DeadLock>：是指兩個或兩個以上的進程在執行過程當中,因爭奪資源而形成的一種互相等待的現象,若無外力做用，它們都將沒法推動下去.此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱爲死鎖進程。表級鎖不會產生死鎖.因此解決死鎖主要仍是針對於最經常使用的InnoDB。

死鎖的關鍵在於：兩個(或以上)的Session加鎖的順序不一致。

那麼對應的解決死鎖問題的關鍵就是：讓不一樣的session加鎖有次序

二、產生示例：

案例一

需求：將投資的錢拆成幾份隨機分配給借款人。

起初業務程序思路是這樣的：

投資人投資後，將金額隨機分爲幾份，而後隨機從借款人表裏面選幾個，而後經過一條條select for update 去更新借款人表裏面的餘額等。

例如兩個用戶同時投資，A用戶金額隨機分爲2份，分給借款人1，2

B用戶金額隨機分爲2份，分給借款人2，1

因爲加鎖的順序不同，死鎖固然很快就出現了。

對於這個問題的改進很簡單，直接把全部分配到的借款人直接一次鎖住就好了。

Select * from xxx where id in (xx,xx,xx) for update

在in裏面的列表值mysql是會自動從小到大排序，加鎖也是一條條從小到大加的鎖

例如（如下會話id爲主鍵）：

Session1:

mysql> select * from t3 where id in (8,9) for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
|  8 | WA     | f    | 2016-03-02 11:36:30 |
|  9 | JX     | f    | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+
rows in set (0.04 sec)
Session2:
select * from t3 where id in (10,8,5) for update;
鎖等待中……

其實這個時候id=10這條記錄沒有被鎖住的，但id=5的記錄已經被鎖住了，鎖的等待在id=8的這裏
不信請看

Session3:
mysql> select * from t3 where id=5 for update;
鎖等待中


Session4:
mysql> select * from t3 where id=10 for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
| 10 | JB     | g    | 2016-03-10 11:45:05 |
+----+--------+------+---------------------+
row in set (0.00 sec)
在其它session中id=5是加不了鎖的，可是id=10是能夠加上鎖的。

案例二

在開發中，常常會作這類的判斷需求：根據字段值查詢（有索引），若是不存在，則插入；不然更新。

以id爲主鍵爲例，目前尚未id=22的行

Session1:
select * from t3 where id=22 for update;
Empty set (0.00 sec)

session2:
select * from t3 where id=23  for update;
Empty set (0.00 sec)

Session1:
insert into t3 values(22,'ac','a',now());
鎖等待中……

Session2:
insert into t3 values(23,'bc','b',now());
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

當對存在的行進行鎖的時候(主鍵)，mysql就只有行鎖。

當對未存在的行進行鎖的時候(即便條件爲主鍵)，mysql是會鎖住一段範圍（有gap鎖）

鎖住的範圍爲：

(無窮小或小於表中鎖住id的最大值，無窮大或大於表中鎖住id的最小值)

如：若是表中目前有已有的id爲（11 ， 12）

那麼就鎖住（12，無窮大）

若是表中目前已有的id爲（11 ， 30）

那麼就鎖住（11，30）

對於這種死鎖的解決辦法是：

insert into t3(xx,xx) on duplicate key update `xx`='XX';

用mysql特有的語法來解決此問題。由於insert語句對於主鍵來講，插入的行無論有沒有存在，都會只有行鎖

案例三

mysql> select * from t3 where id=9 for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
|  9 | JX     | f    | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+

row in set (0.00 sec)
Session2:
mysql> select * from t3 where id<20 for update;
鎖等待中

Session1:
mysql> insert into t3 values(7,'ae','a',now());
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

這個跟案例一其它是差很少的狀況，只是session1不按常理出牌了，

Session2在等待Session1的id=9的鎖，session2又持了1到8的鎖（注意9到19的範圍並無被session2鎖住），最後，session1在插入新行時又得等待session2,故死鎖發生了。

這種通常是在業務需求中基本不會出現，由於你鎖住了id=9，卻又想插入id=7的行，這就有點跳了，固然確定也有解決的方法，那就是重理業務需求，避免這樣的寫法。

案例四

通常的狀況，兩個session分別經過一個sql持有一把鎖，而後互相訪問對方加鎖的數據產生死鎖。

案例五

兩個單條的sql語句涉及到的加鎖數據相同，可是加鎖順序不一樣，致使了死鎖。

案例六

http://hedengcheng.com/?p=844

死鎖場景以下：

表結構：

CREATE TABLE dltask (
    id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT ‘auto id’,
    a varchar(30) NOT NULL COMMENT ‘uniq.a’,
    b varchar(30) NOT NULL COMMENT ‘uniq.b’,
    c varchar(30) NOT NULL COMMENT ‘uniq.c’,
    x varchar(30) NOT NULL COMMENT ‘data’,   
    PRIMARY KEY (id),
    UNIQUE KEY uniq_a_b_c (a, b, c)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’deadlock test’;

a，b，c三列，組合成一個惟一索引，主鍵索引爲id列。

事務隔離級別：

RR (Repeatable Read)

每一個事務只有一條SQL：

delete from dltask where a=? and b=? and c=?;

SQL的執行計劃：

死鎖日誌：

衆所周知，InnoDB上刪除一條記錄，並非真正意義上的物理刪除，而是將記錄標識爲刪除狀態。(注：這些標識爲刪除狀態的記錄，後續會由後臺的Purge操做進行回收，物理刪除。可是，刪除狀態的記錄會在索引中存放一段時間。) 在RR隔離級別下，惟一索引上知足查詢條件，可是倒是刪除記錄，如何加鎖？InnoDB在此處的處理策略與前兩種策略均不相同，或者說是前兩種策略的組合：對於知足條件的刪除記錄，InnoDB會在記錄上加next key lock X(對記錄自己加X鎖，同時鎖住記錄前的GAP，防止新的知足條件的記錄插入。) Unique查詢，三種狀況，對應三種加鎖策略，總結以下：

此處，咱們看到了next key鎖，是否很眼熟？對了，前面死鎖中事務1，事務2處於等待狀態的鎖，均爲next key鎖。明白了這三個加鎖策略，其實構造必定的併發場景，死鎖的緣由已經呼之欲出。可是，還有一個前提策略須要介紹，那就是InnoDB內部採用的死鎖預防策略。

• 找到知足條件的記錄，而且記錄有效，則對記錄加X鎖，No Gap鎖(lock_mode X locks rec but not gap)；

• 找到知足條件的記錄，可是記錄無效(標識爲刪除的記錄)，則對記錄加next key鎖(同時鎖住記錄自己，以及記錄以前的Gap：lock_mode X);

• 未找到知足條件的記錄，則對第一個不知足條件的記錄加Gap鎖，保證沒有知足條件的記錄插入(locks gap before rec)；

死鎖預防策略

InnoDB引擎內部(或者說是全部的數據庫內部)，有多種鎖類型：事務鎖(行鎖、表鎖)，Mutex(保護內部的共享變量操做)、RWLock(又稱之爲Latch，保護內部的頁面讀取與修改)。

InnoDB每一個頁面爲16K，讀取一個頁面時，須要對頁面加S鎖，更新一個頁面時，須要對頁面加上X鎖。任何狀況下，操做一個頁面，都會對頁面加鎖，頁面鎖加上以後，頁面內存儲的索引記錄纔不會被併發修改。

所以，爲了修改一條記錄，InnoDB內部如何處理：

• 根據給定的查詢條件，找到對應的記錄所在頁面；

• 對頁面加上X鎖(RWLock)，而後在頁面內尋找知足條件的記錄；

• 在持有頁面鎖的狀況下，對知足條件的記錄加事務鎖(行鎖：根據記錄是否知足查詢條件，記錄是否已經被刪除，分別對應於上面提到的3種加鎖策略之一)；

死鎖預防策略：相對於事務鎖，頁面鎖是一個短時間持有的鎖，而事務鎖(行鎖、表鎖)是長期持有的鎖。所以，爲了防止頁面鎖與事務鎖之間產生死鎖。InnoDB作了死鎖預防的策略：持有事務鎖(行鎖、表鎖)，能夠等待獲取頁面鎖；但反之，持有頁面鎖，不能等待持有事務鎖。

根據死鎖預防策略，在持有頁面鎖，加行鎖的時候，若是行鎖須要等待。則釋放頁面鎖，而後等待行鎖。此時，行鎖獲取沒有任何鎖保護，所以加上行鎖以後，記錄可能已經被併發修改。所以，此時要從新加回頁面鎖，從新判斷記錄的狀態，從新在頁面鎖的保護下，對記錄加鎖。若是此時記錄未被併發修改，那麼第二次加鎖可以很快完成，由於已經持有了相同模式的鎖。可是，若是記錄已經被併發修改，那麼，就有可能致使本文前面提到的死鎖問題。

以上的InnoDB死鎖預防處理邏輯，對應的函數，是row0sel.c::row_search_for_mysql()。感興趣的朋友，能夠跟蹤調試下這個函數的處理流程，很複雜，可是集中了InnoDB的精髓。

剖析死鎖的成因

作了這麼多鋪墊，有了Delete操做的3種加鎖邏輯、InnoDB的死鎖預防策略等準備知識以後，再回過頭來分析本文最初提到的死鎖問題，就會手到拈來，事半而功倍。

首先，假設dltask中只有一條記錄：(1, ‘a’, ‘b’, ‘c’, ‘data’)。三個併發事務，同時執行如下的這條SQL：

delete from dltask where a=’a’ and b=’b’ and c=’c’;

而且產生了如下的併發執行邏輯，就會產生死鎖：

上面分析的這個併發流程，完整展示了死鎖日誌中的死鎖產生的緣由。其實，根據事務1步驟6，與事務0步驟3/4之間的順序不一樣，死鎖日誌中還有可能產生另一種狀況，那就是事務1等待的鎖模式爲記錄上的X鎖 + No Gap鎖(lock_mode X locks rec but not gap waiting)。這第二種狀況，也是」潤潔」同窗給出的死鎖用例中，使用MySQL 5.6.15版本測試出來的死鎖產生的緣由。

此類死鎖，產生的幾個前提：

• Delete操做，針對的是惟一索引上的等值查詢的刪除；(範圍下的刪除，也會產生死鎖，可是死鎖的場景，跟本文分析的場景，有所不一樣)

• 至少有3個(或以上)的併發刪除操做；

• 併發刪除操做，有可能刪除到同一條記錄，而且保證刪除的記錄必定存在；

• 事務的隔離級別設置爲Repeatable Read，同時未設置innodb_locks_unsafe_for_binlog參數(此參數默認爲FALSE)；(Read Committed隔離級別，因爲不會加Gap鎖，不會有next key，所以也不會產生死鎖)

• 使用的是InnoDB存儲引擎；(廢話！MyISAM引擎根本就沒有行鎖)

最後

感謝你們看到這裏，文章有不足，歡迎你們指出；若是你以爲寫得不錯，那就給我一個贊吧。

也歡迎你們關注個人公衆號：程序員麥冬，麥冬天天都會分享java相關技術文章或行業資訊，歡迎你們關注和轉發文章！