Een transactie groepeert statements tot één atomaire eenheid: ofwel committen ze allemaal, ofwel rollen ze allemaal terug, wat de A, C, I, D van ACID geeft. Het isolation level stelt de "I" af — hoeveel gelijktijdige transacties van elkaars niet-gecommitte of veranderende data kunnen zien.
| Level | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | mogelijk | mogelijk | mogelijk |
| READ COMMITTED | nee | mogelijk | mogelijk |
| REPEATABLE READ (InnoDB-standaard) | nee | nee | meestal niet* |
| SERIALIZABLE | nee | nee | nee |
*InnoDB's REPEATABLE READ gebruikt MVCC (elke transactie leest een consistente snapshot) plus next-key locks, dus het blokkeert ook de meeste phantoms — sterker dan de SQL-standaard vereist.
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
Houd de InnoDB-standaard (REPEATABLE READ) aan tenzij je een reden hebt. READ COMMITTED (waar Postgres/Oracle op standaard staan) vermindert lock-contentie voor systemen met veel writes; SERIALIZABLE is correct maar serialiseert conflicterend werk en kan vaker deadlocken.
Isolatie is de knop tussen correctheid en concurrency. Deze anomalieën begrijpen laat je bugs verklaren zoals "het totaal klopte niet onder belasting" en een level kiezen dat geldbewegende transacties correct houdt zonder de throughput onnodig te knijpen.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren