Analyser les interblocages InnoDB et les journaliser tous

Commande

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

Ce que fait la commande

Montre les deux transactions de l'interblocage, le verrou que chacune détient et attend (index, lock_mode, enregistrement) et celle qu'InnoDB a annulée ; le compteur suit la fréquence et le journal d'erreurs conserve les interblocages passés.

Quand l'utiliser

Quand l'application reçoit l'erreur 1213 'Deadlock found when trying to get lock' ou que les alertes d'interblocage augmentent.

Attention

LATEST DETECTED DEADLOCK ne conserve que le dernier événement et est perdu au redémarrage. Le nom d'index et le lock_mode (X, S, gap, insert intention) des lignes 'HOLDS THE LOCK(S)' / 'WAITING FOR THIS LOCK TO BE GRANTED' expliquent la cause ; 'WE ROLL BACK TRANSACTION (n)' indique la victime. Sur 1213, l'application doit rejouer toute la transaction. Correctifs durables : accéder aux lignes dans un ordre cohérent, garder les transactions courtes, utiliser le bon index pour réduire les gap locks et READ COMMITTED quand c'est approprié. log_error_verbosity=3 active aussi tous les messages Note ; surveillez la croissance du journal d'erreurs. La variable de statut Innodb_deadlocks n'existe pas dans MySQL Community ; utilisez INNODB_METRICS pour le compteur.