一 前言
工欲善其事必先利其器，前面分析了很多死鎖案例，並沒有詳細的介紹如何通過死鎖日志來診斷死鎖的成因。本文將介紹如何讀懂死鎖日志，盡可能的獲取信息來輔助我們解決死鎖問題。
二 日志分析
2.1 場景
為了更好的學習死鎖日志，我們需要提前了解死鎖場景
MySQL 5.6 事務隔離級別為RR
CREATE TABLE `ty` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idxa` (`a`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8mb4
insert into ty(a,b) values(2,3),(5,4),(6,7);
2.2 測試用例
| T2 |
T1 |
| begin; |
|
| delete from ty where a=5; |
begin; |
| delete from ty where a=5; |
|
| insert into ty(a,b) values(2,10); |
|
| delete from ty where a=5; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
2.3 我們通過show engine innodb status 查看的日志是最新一次記錄死鎖的日志。
------------------------
LATEST DETECTED DEADLOCK
------------------------
2017-09-09 22:34:13 7f78eab82700
*** (1) TRANSACTION: #事務1
TRANSACTION 462308399, ACTIVE 33 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 3525577, OS thread handle 0x7f896cc4b700, query id 780039657 localhost root updating
delete from ty where a=5
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308399 lock_mode X waiting
*** (2) TRANSACTION:
TRANSACTION 462308398, ACTIVE 61 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1184, 4 row lock(s), undo log entries 2
MySQL thread id 3525490, OS thread handle 0x7f78eab82700, query id 780039714 localhost root update
insert into ty(a,b) values(2,10)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X locks gap before rec insert intention waiting
*** WE ROLL BACK TRANSACTION (1)
2.4 日志分析
*** (1) TRANSACTION: #事務1
TRANSACTION 462308399, ACTIVE 33 sec starting index read
事務編號為 462308399 ，活躍33秒，starting index read 表示事務狀態為根據索引讀取數據。常見的其他狀態:
fetching rows 表示事務狀態在row_search_for_mysql中被設置，表示正在查找記錄。
updating or deleting 表示事務已經真正進入了Update/delete的函數邏輯（row_update_for_mysql）
thread declared inside InnoDB 說明事務已經進入innodb層。通常而言 不在innodb層的事務大部分是會被回滾的。
mysql tables in use 1, 說明當前的事務使用一個表。locked 1 表示表上有一個表鎖,對於DML語句為LOCK_IX
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
LOCK WAIT表示正在等待鎖, 2 lock struct(s) 表示trx->trx_locks鎖鏈表的長度為2，每個鏈表節點代表該事務持有的一個鎖結構，包括表鎖，記錄鎖以及auto_inc鎖等。本案例中2locks 表示IX鎖和 lock_mode X (Next-key lock)
heap size 360 表示事務分配的鎖堆內存大小,一般沒有什么具體的用處。
1 row lock(s)表示當前事務持有的行記錄鎖/gap 鎖的個數。
delete from ty where a=5 表示事務1在執行的sql ，不過比較悲傷的事情是show engine innodb status 是查看不到完整的事務的sql 的，通常顯示當前正在等待鎖的sql。
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308399 lock_mode X waiting
RECORD LOCKS 表示記錄鎖,space id為219,page號4 ，n bits 72表示這個聚集索引記錄鎖結構上留有72個Bit位
表示事務1 正在等待表 ty 上的 idxa 的 X 鎖本案例中其實是Next-Key lock
事務2的log 和上面分析類似，
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X
顯示了事務2 insert into ty(a,b) values(2,10)持有了a=5 的Lock mode X |LOCK_GAP ，不過我們從日志里面看不到 事務2 執行的 delete from ty where a=5;這點也是造成DBA 僅僅根據日志難以分析死鎖的問題的根本原因。
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X locks gap before rec insert intention waiting
表示事務2的insert 語句正在等待插入意向鎖 lock_mode X locks gap before rec insert intention waiting (LOCK_X + LOCK_REC_GAP )
這里需要各位注意的是鎖組合，類似lock_mode X waiting ,lock_mode X,lock_mode X locks gap before rec insert intention waiting 是我們分析死鎖的核心重點。如何理解鎖組合呢？
首先我們要知道對於MySQL有兩種常規鎖模式
LOCK_S（讀鎖，共享鎖）
LOCK_X（寫鎖，排它鎖）
最容易理解的鎖模式，讀加共享鎖，寫加排它鎖.
有如下幾種鎖的屬性
LOCK_REC_NOT_GAP （鎖記錄）
LOCK_GAP （鎖記錄前的GAP）
LOCK_ORDINARY （同時鎖記錄+記錄前的GAP 。傳說中的Next Key鎖）
LOCK_INSERT_INTENTION（插入意向鎖，其實是特殊的GAP鎖）
鎖的屬性可以與鎖模式任意組合。例如.
lock->type_mode 可以是Lock_X 或者Lock_S
locks gap before rec 表示為gap鎖：lock->type_mode & LOCK_GAP
locks rec but not gap 表示為記錄鎖，非gap鎖：lock->type_mode & LOCK_REC_NOT_GAP
insert intention 表示為插入意向鎖：lock->type_mode & LOCK_INSERT_INTENTION
waiting 表示鎖等待：lock->type_mode & LOCK_WAIT
三 小結
本文算是簡單的死鎖分析入門，能夠提供部分死鎖分析的所需要的技術知識。死鎖分析確是一門技術活兒，想要透徹的分析死鎖的成因，我們必須要了解造成死鎖的業務邏輯sql 的執行場景，MySQL的鎖機制 ，各種鎖之間的兼容性,必要時還需要透徹的理解源碼。
----
1. mysql都有什么鎖
MySQL有三種鎖的級別：頁級、表級、行級。
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高,並發度最低。
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低,並發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般
算法：
next KeyLocks鎖，同時鎖住記錄(數據)，並且鎖住記錄前面的Gap
Gap鎖，不鎖記錄，僅僅記錄前面的Gap
Recordlock鎖（鎖數據，不鎖Gap）
所以其實 Next-KeyLocks=Gap鎖+ Recordlock鎖
2. 什么情況下會造成死鎖
所謂死鎖<DeadLock>: 是指兩個或兩個以上的進程在執行過程中,
因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去.
此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等竺的進程稱為死鎖進程.
表級鎖不會產生死鎖.所以解決死鎖主要還是針對於最常用的InnoDB.
死鎖的關鍵在於：兩個(或以上)的Session加鎖的順序不一致。
那么對應的解決死鎖問題的關鍵就是：讓不同的session加鎖有次序
3. 一些常見的死鎖案例
案例一：
需求：將投資的錢拆成幾份隨機分配給借款人。
起初業務程序思路是這樣的：
投資人投資后，將金額隨機分為幾份，然后隨機從借款人表里面選幾個，然后通過一條條select for update 去更新借款人表里面的余額等。
抽象出來就是一個session通過for循環會有幾條如下的語句：
Select * from xxx where id='隨機id' 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 | +----+--------+------+---------------------+ 2 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 | +----+--------+------+---------------------+ 1 row in set (0.00 sec) 在其它session中id=5是加不了鎖的，但是id=10是可以加上鎖的。
案例2：
在開發中，經常會做這類的判斷需求：根據字段值查詢（有索引），如果不存在，則插入；否則更新。
以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語句對於主鍵來說，插入的行不管有沒有存在，都會只有行鎖。
案例3：
直接上情景：
mysql> select * from t3 where id=9 for update; +----+--------+------+---------------------+ | id | course | name | ctime | +----+--------+------+---------------------+ | 9 | JX | f | 2016-03-01 11:36:30 | +----+--------+------+---------------------+ 1 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的行，這就有點跳了，當然肯定也有解決的方法，那就是重理業務需求，避免這樣的寫法。
附記，推薦兩篇好文章
案例4：
MySQL 加鎖處理分析：
轉自葉老師的微信公眾號