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

当然，

\n\n

刚刚在 5.6 中为我的一位客户解决了这个问题。实际上这些都是innodb死锁，select后面跟着更新导致了死锁。请更新查询并进行单独更新。

\n\n

你有从服务器吗？

\n\n

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

\n