En transaktion grupperer statements i én atomisk enhed: enten committer alle, eller alle rulles tilbage, hvilket giver A, C, I, D i ACID. Isolationsniveauet justerer "I"'et — hvor meget samtidige transaktioner kan se af hinandens ucommittede eller foranderlige data.
| Niveau | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | muligt | muligt | muligt |
| READ COMMITTED | nej | muligt | muligt |
| REPEATABLE READ (InnoDB-standard) | nej | nej | for det meste nej* |
| SERIALIZABLE | nej | nej | nej |
*InnoDB's REPEATABLE READ bruger MVCC (hver transaktion læser et konsistent snapshot) plus next-key locks, så den blokerer også de fleste phantoms — stærkere, end SQL-standarden kræver.
SELECT @@transaction_isolation; -- REPEATABLE-READ by default
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- snapshot taken here
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- both updates apply, or ROLLBACK undoes both
Behold InnoDB-standarden (REPEATABLE READ), medmindre du har en grund. READ COMMITTED (som Postgres/Oracle bruger som default) reducerer lock-contention for systemer med mange writes; SERIALIZABLE er korrekt, men serialiserer konfliktende arbejde og kan deadlocke oftere.
Isolation er drejeknappen mellem korrekthed og samtidighed. At forstå disse anomalier lader dig forklare bugs som "totalen gik ikke op under belastning" og vælge et niveau, der holder pengeflyttende transaktioner korrekte uden unødigt at kvæle throughput.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér