SQL isolation levels and the anomalies they prevent

WHAT THIS TESTS The question checks whether you can connect each isolation level to the concrete read anomaly it eliminates, and whether you understand that the ANSI standard and real implementations diverge.

A GOOD ANSWER COVERS Four levels in increasing strictness. Read Uncommitted allows a transaction to see another transaction's uncommitted writes, a dirty read. Read Committed prevents dirty reads because you only see committed data, but the same query can return different committed values if another transaction commits between reads, a non-repeatable read. Repeatable Read prevents non-repeatable reads by giving a stable view of rows you have read, but new rows matching a predicate can still appear, a phantom. Serializable prevents phantoms too and guarantees the outcome equals some serial ordering of transactions.

COMMON WRONG ANSWERS Saying Serializable means transactions literally run one at a time; it only means the result is equivalent to a serial order. Claiming all databases implement Repeatable Read the same way; Postgres uses snapshot isolation there. Forgetting write skew, an anomaly snapshot isolation allows but true serializable forbids.

LIKELY FOLLOW-UPS What is write skew, how does MVCC implement these levels, what is the performance cost of Serializable, and how does Postgres Serializable Snapshot Isolation detect conflicts.

ONE CONCRETE EXAMPLE Under Read Committed a report summing account balances may read account A before a transfer and account B after, producing an inconsistent total. Repeatable Read fixes that by freezing the snapshot, but two doctors both reading on-call counts and each going off duty illustrates write skew that only Serializable prevents.