试图理解InnoDB表上的MySQL死锁

我试图理解MySQL在同一个表上的并发客户端处理期间发现的死锁 . 这是“SHOW InnoDB STATUS”命令的有趣部分:

------------------------
LATEST DETECTED DEADLOCK
------------------------
120704 16:17:51
*** (1) TRANSACTION:
TRANSACTION 0 3547576, ACTIVE 0 sec, process no 10886, OS thread id 140547111458560 inserting
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 368, 1 row lock(s), undo log entries 1
MySQL thread id 41941, query id 1725666 localhost testsuite update
insert into `INode` (`status`,`_type`,`group`,`ctime`,`parent`,`shared`,`basename`,`_rowid`,`displayname`,`user`,`content_type`,`mtime`,`position`,`atime`,`size`) values ('Published','Group','12','2012-07-04 16:17:48.996869','2',null,'1','12','1','3','application/x-empty','2012-07-04 16:17:48.996896','1','2012-07-04 16:17:48.996914',null)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 5554 n bits 80 index `INodeparent_basename` of table `testsuite`.`INode` trx id 0 3547576 lock mode S waiting
Record lock, heap no 12 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 80000002; asc     ;; 1: len 1; hex 31; asc 1;; 2: len 4; hex 8000000b; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 0 3547575, ACTIVE 0 sec, process no 10886, OS thread id 140547107845888 inserting, thread declared inside InnoDB 493
mysql tables in use 1, locked 1
13 lock struct(s), heap size 3024, 17 row lock(s), undo log entries 21
MySQL thread id 41940, query id 1725808 localhost testsuite update
replace into `INode` (`status`,`_type`,`position`,`group`,`ctime`,`parent`,`basename`,`_rowid`,`displayname`,`user`,`content_type`,`mtime`,`shared`,`atime`,`size`) values ('Published','Group','0','2','2012-07-04 16:17:49','1','groups','2','admin','3','application/x-empty','2012-07-04 16:17:49',null,'2012-07-04 16:17:49',null),('Published','Group','1','11','2012-07-04 16:17:51.064074','2','1','11','1','3','inode/directory','2012-07-04 16:17:51.064074',null,'2012-07-04 16:17:51.064074',null)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 5554 n bits 80 index `INodeparent_basename` of table `testsuite`.`INode` trx id 0 3547575 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 67726f757073; asc groups;; 2: len 4; hex 80000002; asc     ;;

Record lock, heap no 12 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 80000002; asc     ;; 1: len 1; hex 31; asc 1;; 2: len 4; hex 8000000b; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 5554 n bits 80 index `INodeparent_basename` of table `testsuite`.`INode` trx id 0 3547575 lock_mode X waiting
Record lock, heap no 12 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 80000002; asc     ;; 1: len 1; hex 31; asc 1;; 2: len 4; hex 8000000b; asc     ;;

*** WE ROLL BACK TRANSACTION (1)

我从这个日志中理解的是,事务(1)正在等待在表 testsuite 的索引 INodeparent_basename 上获得共享锁 . INode . 现在,transaction(2)对同一个索引具有独占锁定 . 但奇怪的是,事务(2)也在等待给定表的X锁定 . 这是为什么?如果事务(2)已经有锁,为什么要等呢?

(一般来说,我没有找到任何文件准确地解释了如何读取状态命令的输出 - 如果有人可以指出我也会很有趣)

回答(2)

3 years ago

在这种情况下,事务2获取了先前语句的共享锁 . (*(2)HOLDS THE LOCK(S):)

然后,事务1尝试获取同一行上的独占锁,并等待删除共享锁 .

然后,在另一个语句中,事务2尝试获取同一行上的独占锁 . 发生了死锁 .

3 years ago

我不知道它是否会有所帮助,但要考虑的一件事是导致锁定的操作顺序 . 看来,在应用程序的一个位置,您正在创建锁定,例如

表1表2

在另一个做

表2表1(仅示例)

在没有看到实际代码的情况下,我建议调查这样的事情并确保你按照相同的工作/更新/插入记录顺序执行它们,这样它们都可以像

从表1插入/更新然后插入/更新表2

这样,首先在表1上首先尝试第一次锁定 . 如果不能这样做,那么在表1发布之前它甚至不会尝试表2 .

然后,对表2应用任何更改并完成您的交易 . 当表2和1都被释放时,表1上等待释放的下一个事务可以继续 .