如何理解死锁的原因--即如何找出哪些事务捕获了哪些锁?
我的engine.log文件具有以下死锁:
------------------------
LATEST DETECTED DEADLOCK
------------------------
170327 11:09:53
*** (1) TRANSACTION:
TRANSACTION 4 2719072253, ACTIVE 5 sec, OS thread id 26215 starting index read
...
INSERT INTO... (the first transaction)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 36025889 n bits 96 index `PRIMARY` of table `mydb`.`mytable` trx id 4 2719072253 lock mode S locks rec but not gap waiting
...
*** (2) TRANSACTION:
TRANSACTION 4 2719072205, ACTIVE 35 sec, OS thread id 25564 starting index read, thread declared inside InnoDB 485
UPDATE ... (the second transaction)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 36025889 n bits 96 index `PRIMARY` of table `mydb`.`mytable` trx id 4 2719072205 lock_mode X locks rec but not gap
Record lock, heap no 27 PHYSICAL RECORD: n_fields 72; compact format; info bits 0
...
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 42767646 n bits 120 index `PRIMARY` of table `mydb`.`mytable` trx id 4 2719072205 lock_mode X locks rec but not gap waiting
...
*** WE ROLL BACK TRANSACTION (1)
我对日志中描述的内容的设想如下:
1.事务№2最初只有一个锁(从日志中不清楚锁的类型):
* (2)锁(S) 记录锁空间id 0页编号36025889 n位96索引主表的mydb.mytable trx id 4 2719072205 lock_mode x锁 记录锁,堆编号为27物理记录: n_fields 72;压缩格式;info位0
2.事务№1试图获得S类型的锁:
* (1)等候批出该锁: 录音锁..。trx id 4 2719072253锁模式S锁rec,而不是间隙等待
尝试失败后,开始等待事务№2锁的释放;
3.然后,事务№2试图获得X类型的锁:
* (2)等候批出该锁: 录音锁..。trx id 4 2719072205 lock_mode X锁rec,但没有间隙等待
在尝试失败后,它开始等待事务№1获得S锁并释放它。
我是否正确地理解了日志,或者我的解释是错误的?
发布于 2017-03-28 14:18:23
你的解释几乎是正确的。我想补充几点:
update
,它对正在更新的索引记录持有独占(X)锁。因此,第一个事务无法获得相同记录上的S锁。但是,第二个事务正在等待对不同的记录集授予X锁(page no
不同于其他锁‘)。https://stackoverflow.com/questions/43071383
复制相似问题