I quattro livelli di isolamento
Da Read Uncommitted a Serializable e ciò che ciascun livello consente.
I quattro livelli di isolamento è una lezione Coding Interview Prep gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Coding Interview Prep, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Coding Interview Prep include 4 lezioni in totale.
La domanda dietro la domanda
Quando un intervistatore chiede di "elencare i quattro livelli di isolamento", la vera verifica consiste nel capire se sa spiegare il compromesso: un isolamento più forte significa meno anomalie, ma anche una concorrenza minore.
Lo standard SQL definisce quattro livelli, ordinati dal più debole al più forte:
- READ UNCOMMITTED
- READ COMMITTED
- REPEATABLE READ
- SERIALIZABLE
Ogni livello consente o vieta un insieme specifico di anomalie di lettura. Questa lezione tratta i livelli; la prossima esaminerà le anomalie in dettaglio.
Impostare il livello di isolamento
Il livello di isolamento si imposta per transazione o per sessione. La sintassi è quasi identica tra i vari motori.
Se non lo si imposta, ogni database utilizza un valore predefinito. Conoscere i valori predefiniti è una domanda frequente nei colloqui, quindi li esamineremo alla fine.
-- Per transaction (standard SQL)
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- ... statements ...
COMMIT;
-- Per session
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;Livello 1: READ UNCOMMITTED
READ UNCOMMITTED è il livello più debole. Una transazione può leggere righe modificate da un'altra transazione ma non ancora confermate. Queste vengono chiamate letture sporche.
Se l'altra transazione esegue un rollback, si sono letti dati che non sono mai esistiti ufficialmente. Questo è pericoloso per tutto ciò che deve essere corretto.
Nota: Postgres tratta READ UNCOMMITTED come READ COMMITTED, quindi non esegue mai vere letture sporche. SQL Server e MySQL lo rispettano.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
BEGIN;
-- may see another transaction's uncommitted (dirty) rows
SELECT balance FROM accounts WHERE id = 1;
COMMIT;Livello 2: READ COMMITTED
READ COMMITTED garantisce che vengano letti esclusivamente dati già confermati. Nessuna lettura sporca.
Tuttavia, ogni istruzione vede l'ultimo snapshot confermato. Se si esegue due volte la stessa query all'interno di una transazione, un'altra transazione confermata nel frattempo può modificare il risultato. Questa anomalia è una lettura non ripetibile.
Questo è il valore predefinito in Postgres, Oracle e SQL Server ed è un compromesso ragionevole per la maggior parte delle applicazioni.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT balance FROM accounts WHERE id = 1; -- returns 500
-- another transaction commits an update to id = 1
SELECT balance FROM accounts WHERE id = 1; -- may now return 700
COMMIT;Livello 3: REPEATABLE READ
REPEATABLE READ garantisce che, se si legge due volte una riga nella stessa transazione, si ottenga lo stesso valore entrambe le volte. All'inizio della transazione acquisisce uno snapshot coerente.
Previene le letture sporche e le letture non ripetibili. Lo standard consente comunque le letture fantasma: nuove righe che corrispondono alla clausola WHERE e compaiono ripetendo la query.
Importante: questo è il valore predefinito in MySQL/InnoDB e l'implementazione di InnoDB blocca anche la maggior parte delle letture fantasma tramite i next-key lock.
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT balance FROM accounts WHERE id = 1; -- 500
-- another transaction commits a change to id = 1
SELECT balance FROM accounts WHERE id = 1; -- still 500 in this txn
COMMIT;Livello 4: SERIALIZABLE
SERIALIZABLE è il livello più rigoroso. Il database garantisce che il risultato dell'esecuzione concorrente delle transazioni sia identico a quello ottenuto eseguendole una dopo l'altra secondo un determinato ordine seriale.
Previene le letture sporche, le letture non ripetibili e le letture fantasma. Il costo consiste in un maggior numero di blocchi o, in Postgres, in annullamenti dovuti a errori di serializzazione che devono essere ritentati.
Formulazione da colloquio: "SERIALIZABLE dà l'illusione che ogni transazione sia stata eseguita da sola, al prezzo di una concorrenza ridotta e di possibili nuovi tentativi."
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT SUM(balance) FROM accounts;
INSERT INTO audit (total) VALUES (...);
COMMIT; -- may raise a serialization_failure you retryLa matrice delle anomalie
La cosa più utile da memorizzare è quale anomalia ogni livello consente. "Sì" significa che l'anomalia può verificarsi.
- READ UNCOMMITTED: sporca=Sì, non ripetibile=Sì, fantasma=Sì
- READ COMMITTED: sporca=No, non ripetibile=Sì, fantasma=Sì
- REPEATABLE READ: sporca=No, non ripetibile=No, fantasma=Sì (secondo lo standard)
- SERIALIZABLE: sporca=No, non ripetibile=No, fantasma=No
Ogni passaggio verso l'alto vieta un'anomalia in più. Questa progressione è l'intera risposta.
Standard e implementazioni reali
Una distinzione da livello senior: lo standard SQL definisce i livelli in base alle anomalie che devono prevenire, non al modo in cui lo fanno. I motori reali spesso ne prevengono altre.
- REPEATABLE READ di Postgres usa l'isolamento tramite snapshot e blocca anche le letture fantasma, sebbene possa comunque verificarsi un write skew.
- REPEATABLE READ di MySQL/InnoDB blocca le letture fantasma tramite i next-key lock.
- SERIALIZABLE di Postgres usa SSI (Serializable Snapshot Isolation) e annulla le transazioni in caso di conflitto invece di ricorrere a blocchi pesanti.
Menzionare questo aspetto dimostra che si sa che lo standard rappresenta un livello minimo, non il comportamento esatto.
Livelli predefiniti per motore
I valori predefiniti vengono chiesti molto spesso. Li memorizzi:
- PostgreSQL: READ COMMITTED
- Oracle: READ COMMITTED (mai letture sporche)
- SQL Server: READ COMMITTED
- MySQL (InnoDB): REPEATABLE READ
L'eccezione di MySQL è una domanda-trabocchetto molto comune. Se le viene chiesto "qual è il livello di isolamento predefinito?", chiarisca sempre prima quale motore si sta considerando.
Scegliere un livello nella pratica
Come si decide? Si consideri il compromesso tra rischio e throughput.
- Usi READ COMMITTED per il normale OLTP: è veloce ed evita le letture sporche.
- Usi REPEATABLE READ quando una transazione legge più volte gli stessi dati e questi devono rimanere stabili (report e calcoli in più passaggi).
- Usi SERIALIZABLE per la logica in cui la correttezza è fondamentale e qualsiasi anomalia è inaccettabile, progettando una logica di retry per gli annullamenti.
In produzione, usi READ UNCOMMITTED quasi mai.
Domande frequenti di approfondimento
Dopo aver elencato i livelli, nei colloqui seguono spesso domande rapide. Si prepari a rispondere con precisione:
- "Quale livello previene le letture sporche ma consente quelle non ripetibili?" READ COMMITTED.
- "Qual è l'unica anomalia ancora consentita da REPEATABLE READ secondo lo standard?" Le letture fantasma.
- "Perché non usare sempre SERIALIZABLE?" Riduce la concorrenza e può costringere a ripetere le transazioni in caso di errori di serializzazione.
- "Un livello superiore ha un costo maggiore?" Sì, sotto forma di blocchi oppure di costi dovuti ad annullamento e nuovo tentativo.
Rispondere immediatamente dimostra che la gerarchia è stata interiorizzata, non semplicemente memorizzata.
Verifica rapida
Una di queste informazioni sul livello predefinito è tra quelle verificate più spesso.
Riepilogo: quattro livelli, un compromesso
I quattro livelli di isolamento formano una scala dal più debole al più forte: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE. Ogni passaggio verso l'alto vieta un'anomalia in più (sporca, non ripetibile, fantasma), al costo di una minore concorrenza.
Ricordi i valori predefiniti (READ COMMITTED ovunque, tranne REPEATABLE READ in MySQL) e tenga presente che i motori reali spesso prevengono più anomalie di quanto richiesto dallo standard. Nella prossima lezione esamineremo le tre anomalie di lettura che questi livelli sono progettati per impedire.
Domande Frequenti
La lezione «I quattro livelli di isolamento» è gratuita?
Sì — il testo completo di «I quattro livelli di isolamento» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Coding Interview Prep, passa a CoddyKit PRO. Il corso Coding Interview Prep include 4 lezioni in totale.
Cosa imparerò in «I quattro livelli di isolamento»?
Da Read Uncommitted a Serializable e ciò che ciascun livello consente. Eserciti Coding Interview Prep con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Coding Interview Prep?
Non è richiesta alcuna esperienza precedente. Coding Interview Prep su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.
Quanto tempo richiede la lezione «I quattro livelli di isolamento»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Coding Interview Prep?
Sì. Ogni lezione Coding Interview Prep include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Spiegazione delle proprietà ACID
- I quattro livelli di isolamento
- Letture sporche, non ripetibili e fantasma
- Deadlock, locking e MVCC