剖析6個MySQL死鎖案例的原因以及死鎖預防策略

fly1north發表於2021-04-22

MySQL 死鎖是面試常問問題,金三銀四,所以最近面試相關的文章比較多,本文章是總結的一波死鎖問題,和大家分享一下。

MySQL有三種鎖的級別:頁級、表級、行級。
表級鎖:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖衝突的概率最高,併發度最低。
行級鎖:開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖衝突的概率最低,併發度也最高。
頁面鎖:開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間,併發度演算法:

  • next KeyLocks鎖,同時鎖住記錄(資料),並且鎖住記錄前面的Gap
  • Gap鎖,不鎖記錄,僅僅記錄前面的Gap
  • Recordlock鎖(鎖資料,不鎖Gap)
  • 所以其實 Next-KeyLocks=Gap鎖+ Recordlock鎖
完整版的MySQL學習筆記點選領取

產生原因

所謂死鎖<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語句涉及到的加鎖資料相同,但是加鎖順序不同,導致了死鎖。

案例六

死鎖場景如下:

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引擎根本就沒有行鎖)
本作品採用《CC 協議》,轉載必須註明作者和本文連結

相關文章