用于锁定相同行两次的MySQL 5.6死锁？

Question

我看到MySQL 5.6的死锁，因为似乎想要锁定相同的行两次。

从下面的代码段中，id =（11，12，13，14，15）的行已经有一个锁。而当另一个事务试图获得对这些锁的锁时，MySQL会使检测到死锁的事务失败。

我的阅读是否正确？如果是这样，MySQL 5.6中有什么可以解决这个问题？ FWIW，5.5中的相同代码工作得很好（数百次迭代）。

 
------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
2013-07-25 11:46:05 13a515000 
*** (1) TRANSACTION: 
TRANSACTION 2333130, ACTIVE 0 sec fetching rows 
mysql tables in use 1, locked 1 
LOCK WAIT 31 lock struct(s), heap size 6960, 6 row lock(s) 
MySQL thread id 2944, OS thread handle 0x13ae88000, query id 184533 localhost 127.0.0.1 root Sending data 
SELECT id FROM table_meta WHERE id IN (11, 12, 13, 14, 15) FOR UPDATE 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 128954 page no 5 n bits 176 index `PRIMARY` of table `db_test1`.`table_meta` trx id 2333130 lock_mode X locks rec but not gap waiting 
*** (2) TRANSACTION: 
TRANSACTION 2333255, ACTIVE 0 sec starting index read 
mysql tables in use 1, locked 1 
3 lock struct(s), heap size 1248, 11 row lock(s) 
MySQL thread id 2927, OS thread handle 0x13a515000, query id 186769 localhost 127.0.0.1 root Sending data 
SELECT id FROM table_meta WHERE id IN (1, 2, 3, 4, 5, 6, 8, 10, 11, 12, 13, 14, 15) FOR UPDATE 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 128954 page no 5 n bits 176 index `PRIMARY` of table `db_test1`.`table_meta` trx id 2333255 lock_mode X locks rec but not gap 
*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 128954 page no 5 n bits 176 index `PRIMARY` of table `db_test1`.`table_meta` trx id 2333255 lock_mode X locks rec but not gap waiting 
*** WE ROLL BACK TRANSACTION (2) 

Answer 1

当然，

刚刚整理这在5.6我的一个客户。实际上这些都是innodb死锁，选择之后是导致死锁的更新。请更新查询并做一个单独的更新。

你有从服务器吗？

还有一件事要考虑 - INSERT ... SELECT还执行读锁定模式，因此部分绕过版本控制并检索最新的提交行。因此，即使您在REPEATABLE-READ模式下操作，此操作也将以READ-COMMITTED 模式执行，与纯SELECT所能提供的结果相比，可能会给出不同的结果。顺便说一下，这适用于SELECT .. LOCK IN SHARE MODE和SELECT ... FOR UPDATE。 我的一个问题是，如果我不使用复制，并且禁用了二进制日志？如果未使用复制，则可以启用innodb_locks_unsafe_for_binlog选项，这将放松Innodb在语句执行时设置的锁定，这通常会提供更好的并发性。然而，正如名称所述，它使得锁定在复制和时间点恢复之间不安全，所以谨慎使用innodb_locks_unsafe_for_binlog选项。