Mysql Transaktion wartet auf Sperre, die bereits gewährt wird. Dies führt zu Deadlock

Question

Wenn folgende Situation einen Fehler in mysql ?.

Mysql Version: mysql.x86_64 5.0.77-4.el5_4.1

Kernel: Linux box2 2.6.18-128.el5 # 1 SMP Mi 21. Januar 10.41.14 EST 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

Verwenden SHOW ENGINE INNODB STATUS die Ursache des jüngsten Deadlock zu bestimmen. Dadurch können Sie Ihre Anwendung optimieren, um Deadlocks zu vermeiden.

Immer bereit sein, eine Transaktion erneut auszugeben, wenn sie aufgrund eines Deadlocks fehlschlägt. Deadlocks sind nicht gefährlich. Versuchen Sie es erneut.

Answer 2

Ich lese etwas vor langer Zeit, und nicht sicher, ob es könnte sein, was Sie als Ergebnis oder nicht laufen ... ohne Code der Transaktion des aktuellen zu sehen vs was es widerspricht.

Bei der Verarbeitung Ihrer Transaktionen sollten Sie versuchen, sie immer in der gleichen Reihenfolge sperren zu lassen ... Führen Sie für ein Auftrags-/Auftragsdetail-/Zahlungssystem die Aktivitäten in der hier aufgelisteten Reihenfolge für alle ähnlichen aus. Wenn Sie einen anderen Prozess haben, der seine Transaktion in der Reihenfolge "Order detail/order" ausprobiert, kann dies zu einem Deadlock führen.

Eine Transaktion sperrt zuerst die Bestellnummer und bearbeitet dann die Bestelldetails. Die andere Transaktion sperrt zuerst die Auftragsdetails und versucht dann, den Auftragskopf zu erhalten.

HTH

Answer 3

Manchmal kann die SHOW ENGINE BDB STATUS schwer zu entziffern, weil es nur in der Transaktion die aktuelle Anweisung zeigt. Es werden keine Anweisungen angezeigt, die zuvor in der gleichen Transaktion aufgetreten sind und möglicherweise die tatsächlich gehaltenen Sperren erhalten haben.

In Ihrem Fall hat eine frühere Anweisung in Transaktion 2 eine gemeinsame Sperre für die betreffende Zeile erhalten.

Dann versuchte Transaktion 1, eine exklusive Sperre für die gleiche Zeile zu erwerben, und wartet glücklich, dass die gemeinsame Sperre entfernt wird.

Dann versuchte Transaktion 2 in einer anderen Anweisung, eine exklusive Sperre für dieselbe Zeile zu erhalten. Klassischer Deadlock. Keine Transaktion kann abgeschlossen werden.

Eine Lösung, um einen solchen Deadlock zu vermeiden, wäre eine exklusive Sperre für die Zeile in Transaktion 2 mit einer SELECT FOR UPDATE-Anweisung vor der Anweisung, die die gemeinsame Sperre erhält.