Mysql事务正在等待已被授予的锁。这是造成死锁

Question

如果出现以下情况，mysql中的一个错误？

MySQL版本：mysql.x86_64 5.0.77-4.el5_4.1

内核：Linux的BOX2 2.6.18-128.el5＃1 SMP周三1月21日10时41分14秒东部时间2009 x86_64的x86_64的x86_64的GNU/Linux的

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
100125 4:24:41 
*** (1) TRANSACTION: 
TRANSACTION 0 210510625, ACTIVE 155 sec, process no 28125, OS thread id 1243162944 starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 5 lock struct(s), heap size 1216, undo log entries 1 
MySQL thread id 162928579, query id 527252744 box22 172.16.11.105 user updating 
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210510625 lock_mode X locks rec but not gap waiting 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** (2) TRANSACTION: 
TRANSACTION 0 210505911, ACTIVE 555 sec, process no 28125, OS thread id 1184323904 starting index read, thread declared inside InnoDB 500 
mysql tables in use 1, locked 1 
5 lock struct(s), heap size 1216, undo log entries 1 
MySQL thread id 162924258, query id 527252762 box22 172.16.11.105 user updating 
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock mode S locks rec but not gap 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock_mode X locks rec but not gap waiting 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** WE ROLL BACK TRANSACTION (2) 
------------ 

Answer 1

使用SHOW ENGINE INNODB STATUS来确定最后一个死锁的原因。这可以帮助您调整应用程序以避免死锁。

常作准备，如果它因为死锁而失败重新发出一个事务。僵局并不危险。再试一次。

Answer 2

我读的东西很久以前，不知道这是否可能是你正在运行到结果或不...没有看到目前的交易代码VS它与冲突。

在处理您的交易，你应该设法让他们总是做在同一个序列中的任何锁定......对于订单/订单明细/支付系统，做在这里所有类似列为例如顺序的活动。如果您有另一个按“订单明细/订单”顺序尝试其交易的进程，则可能导致死锁。

一个交易首先锁定订单＃，然后处理订单明细。另一个事务先锁定订单明细，然后尝试获取订单标题。

HTH

Answer 3

有时SHOW ENGINE INNODB STATUS是很难破译，因为它只显示事务当前语句。它不显示先前在同一个事务中发生的可能已经获得实际被保留的锁的语句。

在你的情况，在交易2先前的声明中获得的对有关该行的共享锁。

然后，事务1试图获取在同一行上的排他锁，并且愉快地等待待除去的共享锁。

然后，事务2，在另一份声明，试图获得在同一行上的排他锁。经典的僵局。这两项交易都无法完成。

帮助避免这种死锁的一个解决方案是在获取共享锁的语句之前，使用SELECT FOR UPDATE语句在事务2的行中获取排它锁。