Zakleszczenie MySQL 5.6 do blokowania tych samych wierszy dwa razy?

Question

Widzę impas z MySQL 5.6 z powodu tego, co wydaje się próbować blokować ten sam wiersz/s dwa razy.

Z poniższego fragmentu wiersze, w których id = (11, 12, 13, 14, 15) mają już blokadę. A gdy inna transakcja próbowała uzyskać blokadę, MySQL nie wykrył zakleszczenia transakcji.

Czy moje czytanie jest prawidłowe? Jeśli tak, czy jest coś w MySQL 5.6, aby to rozwiązać? FWIW, ten sam kod w wersji 5.5 działał dobrze (przez kilkaset iteracji).

 
------------------------ 
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

Jasne,

Wystarczy załatwili to dla jednego z moich klientów w 5.6. W rzeczywistości są to zakleszczenia innodb, po którym następuje aktualizacja, która powoduje zakleszczenia. Zaktualizuj zapytanie i wykonaj osobną aktualizację.

Czy masz serwer niewolników?

Jeszcze jedna rzecz do zapamiętania - INSERT ... SELECT wykonuje również odczyt w trybie blokowania, więc częściowo pomija wersję i pobiera ostatnio zatwierdzony wiersz. Więc nawet jeśli pracujesz w trybie REPEATABLE-READ, ta operacja zostanie wykonana w trybie READ-COMMITTED , potencjalnie dając inny wynik w porównaniu do tego, co dałby czysty SELECT. Ta droga ma zastosowanie do SELECT .. LOCK IN SHARE MODE i SELECT ... FOR UPDATE, jak również. Jeden z moich pytań, co jeśli nie używam replikacji i czy mój dziennik binarny jest wyłączony? Jeśli replikacja nie jest używana, można włączyć opcję innodb_locks_unsafe_for_binlog, która rozluźni blokady, które zestawy Innodb wykonują przy wykonywaniu instrukcji, co ogólnie daje lepszą współbieżność. Jednak, jak sama nazwa wskazuje, sprawia, że ​​blokady są niebezpieczne z powodu replikacji i odzyskiwania w czasie, więc ostrożnie używaj opcji innodb_locks_unsafe_for_binlog.