同じ行を2回ロックするためのMySQL 5.6デッドロック？

Question

同じ行/ sを2回ロックしようとしているように思えるので、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の私のクライアントのいずれかのためにこれをソート。実際にはこれらは無駄なデッドロックです。selectに続いてデッドロックを引き起こすアップデートがあります。クエリを更新して別の更新を行ってください。

スレーブサーバーはありますか？

さらに注意すべきことは、INSERT ... SELECTはロックモードで読み込みを実行するため、部分的にバージョニングをバイパスし、最新のコミット済み行を取得します。したがって、REPEATABLE-READモードで操作していても、この操作はREAD-COMMITTEDモードで実行され、純粋なSELECTとは異なる結果が得られる可能性があります。これは、SELECT ... LOCK IN SHARE MODEとSELECT ... FOR UPDATEにも適用されます。 私はレプリケーションを使用していない場合、私のバイナリログを無効にするのはどうですか？レプリケーションを使用しない場合は、Innodbが文の実行時に設定するロックを緩和するinnodb_locks_unsafe_for_binlogオプションを有効にすることができます。これにより、一般に並行性が向上します。しかし、名前が示すように、複製の前にロックが安全でなく、回復が遅れるので、innodb_locks_unsafe_for_binlogオプションは慎重に使用してください。