En transaksjon grupperer setninger i én atomisk enhet: enten committer alle eller så rulles alle tilbake, noe som gir A, C, I, D i ACID. Isolasjonsnivået justerer "I"-en — hvor mye samtidige transaksjoner kan se av hverandres ucommittede eller endrede data.
| Nivå | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | mulig | mulig | mulig |
| READ COMMITTED | nei | mulig | mulig |
| REPEATABLE READ (InnoDB-standard) | nei | nei | stort sett nei* |
| SERIALIZABLE | nei | nei | nei |
*InnoDBs REPEATABLE READ bruker MVCC (hver transaksjon leser et konsistent snapshot) pluss next-key locks, så den blokkerer også de fleste phantoms — sterkere enn SQL-standarden krever.
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) med mindre du har en grunn. READ COMMITTED (som Postgres/Oracle bruker som standard) reduserer lock contention for skrivetunge systemer; SERIALIZABLE er korrekt, men serialiserer motstridende arbeid og kan gi flere deadlocks.
Isolasjon er rattet mellom korrekthet og samtidighet. Å forstå disse anomaliene lar deg forklare feil som "totalen stemte ikke under last" og velge et nivå som holder pengeflyttende transaksjoner korrekte uten å strupe gjennomstrømningen unødvendig.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner