天天看點
傳回

MySQL 死鎖産生原因和解決方法

點選上方 一個優秀的廢人，選擇 設為星标

優質文章，及時送達

blog.csdn.net/tr1912/article/details/81668423

Mysql 鎖類型

一、鎖類型介紹：

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

  • 表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的機率最高，并發度最低。
  • 行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的機率最低，并發度也最高。
  • 頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般

算法：

  • next KeyLocks 鎖，同時鎖住記錄 (資料)，并且鎖住記錄前面的 Gap
  • Gap 鎖，不鎖記錄，僅僅記錄前面的 Gap
  • Recordlock 鎖（鎖資料，不鎖 Gap）
  • 是以其實 Next-KeyLocks=Gap 鎖 + Recordlock 鎖

二、死鎖産生原因和示例

1、産生原因：

所謂死鎖：是指兩個或兩個以上的程序在執行過程中，因争奪資源而造成的一種互相等待的現象，若無外力作用，它們都将無法推進下去。此時稱系統處于死鎖狀态或系統産生了死鎖，這些永遠在互相等待的程序稱為死鎖程序。表級鎖不會産生死鎖。是以解決死鎖主要還是針對于最常用的 InnoDB。

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

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

2、産生示例：

案例一

需求：将投資的錢拆成幾份随機配置設定給借款人。

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

投資人投資後，将金額随機分為幾份，然後随機從借款人表裡面選幾個，然後通過一條條 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 語句對于主鍵來說，插入的行不管有沒有存在，都會隻有行鎖

搜尋 Java 知音公衆号，回複 “後端面試”，送你一份 Java 面試題寶典.pdf

案例三 

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 的行，這就有點跳了，當然肯定也有解決的方法，那就是重理業務需求，避免這樣的寫法。

案例四

MySQL 死鎖産生原因和解決方法

案例四

一般的情況，兩個 session 分别通過一個 sql 持有一把鎖，然後互相通路對方加鎖的資料産生死鎖。

案例五

MySQL 死鎖産生原因和解決方法

案例五

兩個單條的 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 的執行計劃：

MySQL 死鎖産生原因和解決方法

執行計劃

死鎖日志：

MySQL 死鎖産生原因和解決方法

死鎖日志

衆所周知，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 的精髓。搜尋 Java 知音公衆号，回複 “後端面試”，送你一份 Java 面試題寶典.pdf

剖析死鎖的成因

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

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

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

複制

并且産生了以下的并發執行邏輯，就會産生死鎖：

MySQL 死鎖産生原因和解決方法

并發執行邏輯

上面分析的這個并發流程，完整展現了死鎖日志中的死鎖産生的原因。其實，根據事務 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 引擎根本就沒有行鎖)

如何檢測代碼運作是否出現死鎖

  • https://blog.csdn.net/kk185800961/article/details/79528841
  • https://blog.csdn.net/yucaifu1989/article/details/79400446

-END-

如果看到這裡，喜歡這篇文章的話，請幫點個好看。微信搜尋「一個優秀的廢人」，關注後回複「 1024」送你一套完整的 java 教程（包括視訊）。回複「 電子書」送你全程式設計領域電子書 （不隻Java）。

MySQL 死鎖産生原因和解決方法
MySQL 死鎖産生原因和解決方法

教程節選

複制

上一篇: java枚舉類-根據key擷取value及根據value擷取key
下一篇: 手把手教你ShardingSphere和Mybatis攔截器實作特殊字段動态切換加密