2. 程式人生 > 資料庫 >一個mysql死鎖場景例項分析

一個mysql死鎖場景例項分析

阿新 • • 發佈：2020-01-09

前言

最近遇到一個mysql在RR級別下的死鎖問題，感覺有點意思，研究了一下，做個記錄。

涉及知識點：共享鎖、排他鎖、意向鎖、間隙鎖、插入意向鎖、鎖等待佇列

場景

隔離級別：Repeatable-Read

表結構如下

create table t (
 id int not null primary key AUTO_INCREMENT,a int not null default 0,b varchar(10) not null default '',c varchar(10) not null default '',unique key uniq_a_b(a,b),unique key uniq_c(c)
);

初始化資料

insert into t(a,b,c) values(1,'1','1');

有A/B兩個session，按如下順序執行兩個事務

結果是

  • B執行完4之後還是一切正常
  • A執行5的時候，被block
  • B接著執行6，B報死鎖，B回滾，A插入資料

show engine innodb status中可以看到死鎖資訊，這裡先不貼，先解釋幾種鎖的概念，再來理解死鎖過程

共享(S)鎖/互斥(X)鎖

  • 共享鎖允許事務讀取記錄
  • 互斥鎖允許事務讀寫記錄

這兩種其實是鎖的模式可以和行鎖、間隙鎖混搭，多個事務可以同時持有S鎖，但是隻有一個事務能持有X鎖

意向鎖

一種表鎖(也是一種鎖模式)，表明有事務即將給對應表的記錄加S或者X鎖。SELECT ... LOCK IN SHARE MODE會在給記錄加S鎖之前先給表加IS鎖，SELECT ... FOR UPDATE會在給記錄加X鎖之前給表加IX鎖。

這是一種mysql的鎖優化策略，並不是很清楚意向鎖的優化點在哪裡，求大佬指教

兩種鎖的相容情況如下

行鎖

很簡單，給對應行加鎖。比如update、select for update、delete等都會給涉及到的行加上行鎖，防止其他事務的操作

間隙鎖

在RR隔離級別下，為了防止幻讀現象，除了給記錄本身，還需要為記錄兩邊的間隙加上間隙鎖。
比如列a上有一個普通索引，已經有了1、5、10三條記錄，select * from t where a=5 for update除了會給5這條記錄加行鎖，還會給間隙(1,5)和(5,10)加上間隙鎖，防止其他事務插入值為5的資料造成幻讀。
當a上的普通索引變成唯一索引時，不需要間隙鎖，因為值唯一，select * from t where a=5 for update

不可能讀出兩條記錄來。

間隙鎖相互相容，因為如果互斥，事務A持有左半段(1,5)，事務B持有右半段(1,10)，那麼當前面那個例子中a=5的記錄被刪除時，理論上左右兩個間隙鎖得合併成一個新鎖(1,10)，那麼這個新的大範圍鎖屬於誰呢？所以間隙鎖相互相容，不管是S間隙鎖還是X間隙鎖

插入意向鎖

插入意向鎖其實是一種特殊的間隙鎖，從前面對間隙鎖的描述中可以得知，兩個事務在真正insert之前可以同時持有一段間隙的間隙鎖，鎖不住真正insert的這個動作。真正insert之前，mysql還會嘗試獲取對應記錄的插入意向鎖，表明有在間隙中插入一個值的意向。

插入意向鎖和間隙鎖互斥，比如事務1鎖了(1,5)這個間隙，事務2就不能獲取到a=3的插入意向鎖，所以需要鎖等待。

死鎖過程分析

接下來就可以來分析前面那個例子中的死鎖過程了，先看show engine innodb status

 *** (1) TRANSACTION:
TRANSACTION 5967,ACTIVE 8 sec inserting
mysql tables in use 1,locked 1
LOCK WAIT 3 lock struct(s),heap size 1136,2 row lock(s),undo log entries 1
MySQL thread id 9,OS thread handle 140528848688896,query id 537 192.168.128.1 root update
insert into t(a,b) values(0,'0')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 64 page no 4 n bits 72 index uniq_a_b of table `t2`.`t` trx id 5967 lock_mode X locks gap before rec insert intention waiting
Record lock,heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc  ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc  ;;

*** (2) TRANSACTION:
TRANSACTION 5968,ACTIVE 7 sec inserting
mysql tables in use 1,locked 1
3 lock struct(s),undo log entries 1
MySQL thread id 8,OS thread handle 140528848484096,query id 538 192.168.128.1 root update
insert into t(a,'0')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 64 page no 4 n bits 72 index uniq_a_b of table `t2`.`t` trx id 5968 lock_mode X locks gap before rec
Record lock,heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc  ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc  ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 64 page no 4 n bits 72 index uniq_a_b of table `t2`.`t` trx id 5968 lock_mode X locks gap before rec insert intention waiting
Record lock,heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc  ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc  ;;

*** WE ROLL BACK TRANSACTION (2)

session A(即TRANSACTION 5967)正在等待記錄(a=1,b='1')之前的插入意向鎖，session B(即TRANSACTION 5968)持有記錄(a=1,b='1')之前的間隙鎖，卻也在等待那個插入意向鎖。這說的什麼玩意兒，是不是很詭異？

從頭開始分析過程

  1. A、B分別begin，開始事務
  2. A先執行select * from t where a=0 and b='0' for update; ，先加了IX鎖，然後原本意圖為給(0,'0')這條記錄加排他行鎖，但是記錄不存在，所以變成了排他間隙鎖(-∞,1)
  3. B再執行select * from t where a=0 and b='0' for update; ，也是先加了IX鎖，因為記錄不存在，所以加上了排他間隙鎖(-∞,1)，但是由於間隙鎖相互相容，所以沒有block
  4. A執行insert into t(a,'0'); ，這時候，要開始真正insert了，A需要獲得(0,'0')上的插入意向鎖，由於和B持有的(-∞,1)排他間隙鎖衝突，所以鎖等待，進入記錄(0,'0')的鎖等待佇列（雖然記錄並不存在）
  5. B執行insert into t(a,'0'); ，要獲取插入意向鎖，發現雖然B自己是持有(-∞,1)的排他間隙鎖，但是A也有，所以進入等待佇列，等待A釋放
  6. 叮，死鎖發生

死鎖資訊解讀

事務1(TRANSACTION 5967)，等待獲得鎖index uniq_a_b of table t2.t trx id 5967 lock_mode X locks gap before rec insert intention waiting，即在唯一索引uniq_a_b上的插入意向鎖(lock_mode X locks gap before rec insert intention)
鎖的邊界為

 0: len 4; hex 80000001; asc  ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc  ;;

表明兩行記錄

  • 0和1表示uniq_a_b上的值，a=1，b=0x31（即'1'的ascii碼）
  • a=1,b='1'對應的主鍵id=1，因為innodb的索引結構決定的，二級索引(非主鍵索引)指向主鍵索引，主鍵索引再指向資料，所以需要給主鍵加索引

至於int值按位或上的0x80000000就不是很清楚為什麼了，需要大佬解讀

事務2(TRANSACTION 5968)，持有間隙鎖index uniq_a_b of table t2.t trx id 5968 lock_mode X locks gap before rec，等待插入意向鎖index uniq_a_b of table t2.t trx id 5968 lock_mode X locks gap before rec insert intention，所以死鎖發生。

原則上是innodb引擎判斷哪個事務回滾代價小就回滾哪個事務，但是具體評判標準不是很清楚（再一次需要大佬），這裡innodb選擇了回滾事務2。至此，死鎖過程分析完畢

One More Thing

還沒完。。。有個神奇的現象是，如果表結構變成

create table t (
 id int not null primary key AUTO_INCREMENT,unique key uniq_c(c),b)
);
insert into t(a,1,1);

只是把c上的唯一索引uniq_c放到了uniq_a_b前面，那麼最後的死鎖資訊就變了！

 *** (1) TRANSACTION:
TRANSACTION 5801,ACTIVE 5 sec inserting
mysql tables in use 1,locked 1
LOCK WAIT 4 lock struct(s),3 row lock(s),undo log entries 1
MySQL thread id 5,query id 380 192.168.128.1 root update
insert into t2(a,'0')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 5 n bits 72 index uniq_a_b of table `t2`.`t2` trx id 5801 lock_mode X locks gap before rec insert intention waiting
Record lock,heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc  ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc  ;;

*** (2) TRANSACTION:
TRANSACTION 5802,ACTIVE 4 sec inserting
mysql tables in use 1,undo log entries 1
MySQL thread id 6,query id 381 192.168.128.1 root update
insert into t2(a,'0')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 56 page no 5 n bits 72 index uniq_a_b of table `t2`.`t2` trx id 5802 lock_mode X locks gap before rec
Record lock,heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc  ;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc  ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 4 n bits 72 index uniq_c of table `t2`.`t2` trx id 5802 lock mode S waiting
Record lock,heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 0; hex ; asc ;;
 1: len 4; hex 80000002; asc  ;;

*** WE ROLL BACK TRANSACTION (2)

事務2等待的鎖由前面的插入意向鎖變成了共享鎖。什麼鬼？

由於沒看過原始碼，只能根據現象倒推：因為表結構上c的唯一索引在(a,b)前面，而插入的時候沒指定c的值，用的預設值0，innodb需要先去查一下有沒有0這條記錄，有的話就要報唯一鍵衝突了，所以先要加S鎖，但是在(0,'0')這條記錄上已經有了IX鎖，看一下前面的相容性矩陣，S鎖和IX鎖互斥，所以也只能鎖等待

總結

看似一句簡單的select和insert，底下設計非常複雜的鎖機制，理解這些鎖機制有利於寫出高效的SQL(至少是正確的😂)

遺留問題：

  1. 意向鎖的優化點是哪
  2. 鎖資訊裡，行記錄按位或上的0x80000000是啥
  3. 鎖互斥的判定順序，場景1中，(0,'0')上有相容的間隙鎖，也有等待佇列中的鎖，先判定哪個？
  4. innodb計算事務回滾代價的演算法

參考資料

  • http://hedengcheng.com/?p=771
  • https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-insert-intention-locks
  • https://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html
  • https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-understanding-innodb-locking.html

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對我們的支援。

相關推薦

一個mysql死鎖場景例項分析

前言 最近遇到一個mysql在RR級別下的死鎖問題，感覺有點意思，研究了一下，做個記錄。

一個MySQL死鎖問題的復現

很久之前有一個同事問我一個關於死鎖的問題，一直在拖這個事情，總算找了空來看看。

Mysql: 一個死鎖場景的解決

update對資源搶佔的死鎖 業務場景 檔案系統裡面修改檔案的時候，會對上級檔案的修改時間進行修改。由於會同時修改多個檔案，所以，將他們的父目錄收集起來放在set裡面。最後執行update。注意，所有的操作都在一個事務

MySql一個生產死鎖案例分析

接到上級一個生產環境MySQL死鎖日誌資訊檔案，需要找出原因並解決問題。我將死鎖日誌部分貼出如下：

MySQL 間隙鎖導致的死鎖場景分析

實際業務場景 在我們使用mysql的時候，如果不注意間隙鎖容易引起死鎖，最近分析一個業務場景就是間隙鎖導致的死鎖，業務抽象如下：

關於MySQL死鎖問題的深入分析

前言 如果我們的業務處在一個非常初級的階段，併發程度比較低，那麼我們可以幾年都遇不到一次死鎖問題的發生，反之，我們業務的併發程度非常高，那麼時不時爆出的死鎖問題肯定讓我們非常撓頭。不過在死鎖問題發生時，

mysql共享鎖與排他鎖用法例項分析

本文例項講述了mysql共享鎖與排他鎖用法。分享給大家供大家參考，具體如下：

mysql的事務，隔離級別和鎖用法例項分析

本文例項講述了mysql的事務，隔離級別和鎖用法。分享給大家供大家參考，具體如下：

MySQL一次死鎖排查過程分析（雙update）

1.環境 MySQL5.7.26，事務隔離級別為RR 2.表結構 +------------------+------------------+------+-----+---------------------+----------------+

mysql死鎖問題分析

https://blog.csdn.net/BaiHuaXiu123/article/details/54015279 SHOW GLOBAL VARIABLES LIKE \'innodb_deadlock_detect\';SHOW GLOBAL VARIABLES LIKE \'innodb_lock_wait_timeout\';SHOW GLOBAL VARIABLES LIKE \'

MySQL死鎖分析

一、實驗復現 MySQL版本8.0，隔離級別RR和RC均能復現。 1.建立表，構造資料 CREATE TABLE `t2` (

Mysql 死鎖分析

1. 結論 死鎖檢查機制 當事務A需要獲取一個行鎖時（例如更新一行資料），假如需要獲取行1的鎖

線上BUG：MySQL死鎖分析實戰

原文連結：線上BUG：MySQL死鎖分析實戰 1 線上告警 我們不需要關注截圖中得其他資訊，只要能看到列印得org.springframework.dao.DeadlockLoserDataAccessException就足夠了，就是MySQL發生死鎖導致服務拋異常。

MySQL死鎖分析與解決之路

​ 們使用 MySQL 大概率上都會遇到死鎖問題，這實在是個令人非常頭痛的問題。本文將會對死鎖進行相應介紹，對常見的死鎖案例進行相關分析與探討，以及如何去儘可能避免死鎖給出一些建議。

mysql慢查詢操作例項分析【開啟、測試、確認等】

本文例項講述了mysql慢查詢操作。分享給大家供大家參考，具體如下： mysql有些sql會執行很慢，有可能造成伺服器負載飆升

Python使用pymysql模組操作mysql增刪改查例項分析

本文例項講述了Python使用pymysql模組操作mysql增刪改查。分享給大家供大家參考，具體如下：

Django2 連線MySQL及model測試例項分析

本文例項講述了Django2 連線MySQL及model測試。分享給大家供大家參考，具體如下：

MySQL死鎖套路之唯一索引下批量插入順序不一致

前言 死鎖的本質是資源競爭，批量插入如果順序不一致很容易導致死鎖，我們來分析一下這個情況。為了方便演示，把批量插入改寫為了多條 insert。

初學者從原始碼理解MySQL死鎖問題

通過好多個深夜艱難的單步除錯，終於找到了一個理想的斷點，可以看到大部分獲取鎖的過程

由不同的索引更新解決MySQL死鎖套路

前幾篇文章介紹了用原始碼的方式來除錯鎖相關的資訊，這裡同樣用這個工具來解決一個線上實際的死鎖案例，也是我們介紹的第一個兩條 SQL 就造成死鎖的情況。因為線上的表結構比較複雜，做了一些簡化以後如下