Une transaction regroupe des instructions en une seule unité atomique : soit tout est validé, soit tout est annulé, ce qui donne le A, le C, le I, le D d'ACID. Le niveau d'isolation règle le "I" — la mesure dans laquelle des transactions concurrentes peuvent voir les données non validées ou changeantes des autres.
| Niveau | Lecture sale | Lecture non répétable | Lecture fantôme |
|---|---|---|---|
| READ UNCOMMITTED | possible | possible | possible |
| READ COMMITTED | non | possible | possible |
| REPEATABLE READ (défaut InnoDB) | non | non | quasiment non* |
| SERIALIZABLE | non | non | non |
*Le REPEATABLE READ d'InnoDB utilise le MVCC (chaque transaction lit un snapshot cohérent) plus des next-key locks, si bien qu'il bloque aussi la plupart des lectures fantômes — plus fort que ce qu'exige le standard SQL.
SELECT @@transaction_isolation; -- REPEATABLE-READ par défaut
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- snapshot pris ici
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- les deux mises à jour s'appliquent, ou ROLLBACK annule les deux
Gardez le niveau par défaut d'InnoDB (REPEATABLE READ) sauf si vous avez une raison. READ COMMITTED (le défaut de Postgres/Oracle) réduit la contention sur les verrous pour les systèmes à forte écriture ; SERIALIZABLE est correct mais sérialise le travail conflictuel et peut provoquer davantage de deadlocks.
L'isolation est le curseur entre justesse et concurrence. Comprendre ces anomalies vous permet d'expliquer des bugs comme "le total ne tombait pas juste sous charge" et de choisir un niveau qui garde correctes les transactions déplaçant de l'argent sans brider inutilement le débit.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don