InnoDB-Deadlocks analysieren und alle protokollieren

Befehl

-- Latest deadlock: LATEST DETECTED DEADLOCK section (only the most recent is kept)
SHOW ENGINE INNODB STATUS\G
-- Total deadlock counter
SELECT NAME, COUNT FROM information_schema.INNODB_METRICS WHERE NAME = 'lock_deadlocks';
-- Write every deadlock to the error log (logged at Note level, needs verbosity 3)
SET PERSIST innodb_print_all_deadlocks = ON;
SET PERSIST log_error_verbosity = 3;

Was es tut

Zeigt die beiden Transaktionen im Deadlock, die jeweils gehaltene und angeforderte Sperre (Index, lock_mode, Datensatz) und welche InnoDB zurückgerollt hat; der Zähler erfasst die Häufigkeit, das Error Log bewahrt frühere Deadlocks auf.

Wann einsetzen

Wenn die Anwendung den Fehler 1213 'Deadlock found when trying to get lock' erhält oder Deadlock-Alarme zunehmen.

Vorsicht

LATEST DETECTED DEADLOCK enthält nur das letzte Ereignis und geht beim Neustart verloren. Indexname und lock_mode (X, S, gap, insert intention) in den Zeilen 'HOLDS THE LOCK(S)' / 'WAITING FOR THIS LOCK TO BE GRANTED' erklären die Ursache; 'WE ROLL BACK TRANSACTION (n)' zeigt das Opfer. Bei 1213 muss die Anwendung die gesamte Transaktion wiederholen. Dauerhafte Abhilfe: Zeilen in einheitlicher Reihenfolge ansprechen, Transaktionen kurz halten, mit dem richtigen Index Gap Locks reduzieren und wo sinnvoll READ COMMITTED nutzen. log_error_verbosity=3 aktiviert auch alle Note-Meldungen; behalte das Wachstum des Error Logs im Blick. Die Statusvariable Innodb_deadlocks gibt es in MySQL Community nicht; nutze für den Zähler INNODB_METRICS.