Ein Deadlock gibt den Fehler 1213 zurück die Sie clientseitig verarbeiten sollten
Beachten Sie, dass ein Deadlock und ein Lock-Wait verschiedene Dinge sind. In einem Deadlock gibt es keine "fehlgeschlagene" Transaktion:Sie sind beide schuldig. Es gibt keine Garantie, welche zurückgesetzt wird.
Ein Deadlock tritt in einem Szenario wie diesem auf:
UPDATE t_first -- transacion 1 locks t_first
SET id = 1;
UPDATE t_second -- transaction 2 locks t_second
SET id = 2;
UPDATE t_second -- transaction 1 waits for transaction 2 to release the lock on t_second
SET id = 2;
UPDATE t_first -- transaction 2 waits for transaction 1 to release the lock on t_first. DEADLOCK
SET id = 2;
Sind Sie sicher, dass Sie es nicht mit einem Lock Wait verwechseln?
Ein Lock-Wait tritt immer dann auf, wenn eine Transaktion versucht, eine Ressource zu sperren, die bereits von einer anderen Transaktion gesperrt wurde.
Im obigen Beispiel tritt bei Schritt 3 ein Lock-Wait auf .
Da dies eine normale Situation ist (im Gegensatz zu einem Deadlock), die von außen gelöst werden kann, indem die Transaktion, die die Sperre hält, InnoDB festgeschrieben oder rückgängig gemacht wird versucht nicht, die Transaktion rückgängig zu machen, die die Sperre hält.
Stattdessen bricht es einfach die Anweisung ab, die versucht hat, die Sperre zu erlangen, nachdem die Zeitüberschreitung eintritt.
Das Timeout ist standardmäßig 50 Sekunden und wird mit innodb_lock_wait_timeout
.
Die fehlgeschlagene Anweisung (die versucht wurde zu erwerben das Schloss) gibt den Fehler 1205 zurück .
