Una transazione raggruppa più istruzioni in un'unica unità atomica: o committano tutte o vengono annullate tutte, dando la A, C, I, D di ACID. Il livello di isolamento regola la "I" — quanto le transazioni concorrenti possono vedere dei dati non committati o in modifica delle altre.
| Livello | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | possibile | possibile | possibile |
| READ COMMITTED | no | possibile | possibile |
| REPEATABLE READ (default InnoDB) | no | no | quasi mai* |
| SERIALIZABLE | no | no | no |
*Il REPEATABLE READ di InnoDB usa MVCC (ogni transazione legge uno snapshot consistente) più i next-key lock, quindi blocca anche la maggior parte dei phantom — più forte di quanto richieda lo standard SQL.
SELECT @@transaction_isolation; -- REPEATABLE-READ per default
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- lo snapshot viene preso qui
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- entrambi gli update si applicano, oppure ROLLBACK li annulla entrambi
Mantieni il default di InnoDB (REPEATABLE READ) a meno che tu non abbia un motivo. READ COMMITTED (il default di Postgres/Oracle) riduce la contesa sui lock per i sistemi ad alta scrittura; SERIALIZABLE è corretto ma serializza il lavoro in conflitto e può causare più deadlock.
L'isolamento è la manopola tra correttezza e concorrenza. Comprendere queste anomalie ti permette di spiegare bug come "il totale non tornava sotto carico" e di scegliere un livello che mantenga corrette le transazioni che muovono denaro senza limitare inutilmente il throughput.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona