innodb next-key lock引起的死鎖

innodb的事務隔離級別是可重複讀級別且innodb_locks_unsafe_for_binlog禁用，也就是說容許next-key lock

 

CREATE TABLE `LockTest` (
   `order_id` varchar(20) NOT NULL,
   `id` bigint(20) NOT NULL AUTO_INCREMENT,
   PRIMARY KEY (`id`),
   KEY `idx_order_id` (`order_id`)
 ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8

 

事務1	事務2
begin delete from LockTest where order_id =  'D20'
	begin delete from LockTest where order_id =  'D19'
insert into LockTest (order_id) values ('D20')
	insert into LockTest (order_id) values ('D19')
commit	commit

 

事務1 執行到insert語句會block住，事務2執行insert語句會提示死鎖錯誤

 

錯誤碼: 1213
Deadlock found when trying to get lock; try restarting transaction

Execution Time : 00:00:00:000
Transfer Time : 00:00:00:000
Total Time : 00:00:00:000

 

 show engine innodb status 顯示死鎖信息

------------------------
LATEST DETECTED DEADLOCK
------------------------
2014-04-30 15:01:55 a233b90
*** (1) TRANSACTION:
TRANSACTION 596042, ACTIVE 7 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 320, 2 row lock(s), undo log entries 1
MySQL thread id 10851, OS thread handle 0x2abfb90, query id 251521 10.10.53.122 root update
insert into LockTest (order_id) values ('D20')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 502 page no 4 n bits 72 index `idx_order_id` of table `test`.`LockTest` trx id 596042 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) TRANSACTION:
TRANSACTION 596041, ACTIVE 19 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 320, 2 row lock(s), undo log entries 1
MySQL thread id 10848, OS thread handle 0xa233b90, query id 251522 10.10.53.122 root update
insert into LockTest (order_id) values ('D19')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 502 page no 4 n bits 72 index `idx_order_id` of table `test`.`LockTest` trx id 596041 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 502 page no 4 n bits 72 index `idx_order_id` of table `test`.`LockTest` trx id 596041 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** WE ROLL BACK TRANSACTION (2)

 

 

簡單分析上面的場景先刪除再插入的sql是hibernage保存集合關聯的處理方式。delete語句刪除不存在且刪除的order_id大於現有表中的全部order_id,因此delete語句會使用next-key鎖住(當前最大-無窮大) 

lock_id	lock_trx_id	lock_mode	lock_type	lock_table	lock_index	lock_space	lock_page	lock_rec	lock_data
596133:502:4:1	596133	X	RECORD	`test`.`LockTest`	idx_order_id	502	4	1	supremum pseudo-record
596134:502:4:1	596134	X	RECORD	`test`.`LockTest`	idx_order_id	502	4	1	supremum pseudo-record

 

比較奇怪的是爲啥兩個事務都拿到了相同區間的(當前最大-無窮大)的X鎖。不過換成read-commited級別後就沒死鎖了。

終於在官方文檔找到答案, 區間鎖只是用來防止其餘事務在區間中插入數據，區間x鎖 與區間S鎖效果是同樣的。也就是說不會由於兩個事務都用加相同區間鎖而相互等待的

https://dev.mysql.com/doc/refman/5.1/en/innodb-record-level-locks.html

Gap locks in InnoDB are 「purely inhibitive」, which means they only stop other transactions from inserting to the gap. Thus, a gap X-lock has the same effect as a gap S-lock.

 

當兩個事務拿到相同區間鎖後，就會阻止對方忘區間內作insert操做。因此第一個事務insert會阻塞,第二個事務會提示死鎖