InnoDB combine deux mécanismes. Le MVCC permet aux SELECT ordinaires de lire un snapshot cohérent sans verrouiller, si bien que les lecteurs ne bloquent jamais les écrivains. Les protègent les écritures : // prennent des verrous de ligne, et InnoDB utilise aussi des (la ligne + l'intervalle qui la précède) pour empêcher les lectures fantômes sous REPEATABLE READ.
UPDATEDELETESELECT ... FOR UPDATEUn deadlock est un cycle : T1 détient le verrou A et veut B, tandis que T2 détient B et veut A. Aucune ne peut avancer. InnoDB détecte le cycle et annule une transaction (la victime la moins coûteuse) avec l'erreur 1213, de sorte que l'autre aboutit.
-- T1 -- T2
BEGIN; BEGIN;
UPDATE acct SET bal=bal-1 UPDATE acct SET bal=bal-1
WHERE id=1; -- verrouille ligne 1 WHERE id=2; -- verrouille ligne 2
UPDATE acct SET bal=bal+1 UPDATE acct SET bal=bal+1
WHERE id=2; -- attend T2 WHERE id=1; -- attend T1 => DEADLOCK
-- ERROR 1213 : Deadlock found; transaction rolled back
WHERE pour qu'InnoDB verrouille des lignes précises, et non des plages ou (sans index) pratiquement chaque ligne parcourue.SHOW ENGINE INNODB STATUS\G -- LATEST DETECTED DEADLOCK explique qui attendait quoi
En situation de concurrence réelle, la contention sur les verrous et les deadlocks font la différence entre une base qui passe à l'échelle et une base qui se bloque. Savoir que les lecteurs utilisent le MVCC (donc ne bloquent pas), que les deadlocks sont attendus et rejouables, et qu'un ordre de verrouillage cohérent en prévient la plupart est exactement ce qu'exige le travail d'astreinte d'un ingénieur senior.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don