Какие есть уровни изоляции транзакций (Read Uncommitted, Repeatable Read, Serializable)?

Зачем нужны уровни изоляции

При параллельном выполнении транзакций могут возникать эффекты:

• dirty read — чтение незафиксированных (ещё не COMMIT) изменений другой транзакции;

• non‑repeatable read — в рамках одной транзакции один и тот же запрос к одной и той же строке возвращает разные значения (кто‑то другой успел её изменить и закоммитить);

• phantom read — при повторном запросе по одному и тому же условию появляются новые «фантомные» строки, добавленные параллельной транзакцией.

Уровни изоляции определяют, какие из этих эффектов допускаются в обмен на производительность.

READ UNCOMMITTED

Самый слабый уровень:

• может допускать dirty read, non‑repeatable read и phantom read;

• в практике серьёзных СУБД используется редко; многие (например, PostgreSQL) фактически ведут себя как READ COMMITTED, даже если указать READ UNCOMMITTED.

READ COMMITTED

Часто дефолтный уровень (например, в PostgreSQL):

• запрос видит только уже зафиксированные данные: dirty read невозможен;

• между двумя одинаковыми SELECT в одной транзакции данные могут измениться, если другая транзакция их успела изменить и закоммитить (возможен non‑repeatable read и phantom read);

• баланс между корректностью и производительностью для большинства бизнес‑операций.

REPEATABLE READ

Более строгий уровень:

• после того как транзакция прочитала строку, повторное чтение этой же строки вернёт то же значение — non‑repeatable read не допускается;

• в классическом SQL остаются возможны phantom read (новые строки, подпадающие под условие);

• в реализации PostgreSQL на основе MVCC фактически предотвращаются и многие фантомы, но возможны ошибки сериализации, которые нужно перезапускать.

SERIALIZABLE

Самый строгий уровень:

• гарантирует, что результат всех успешно завершённых транзакций эквивалентен некоторому последовательному порядку их выполнения (как будто они шли одна за другой);

• не допускает dirty read, non‑repeatable read, phantom read;

• за счёт этого может чаще приводить к конфликтам и ошибкам сериализации (serialization failure), транзакции нужно уметь перезапускать.

Как ответить на собеседовании

На уровне middle полезно уметь описать разницу так: READ COMMITTED защищает от грязных чтений, но не гарантирует повторяемость; REPEATABLE READ защищает и от грязных, и от неповторяемых чтений, но может допускать фантомы; SERIALIZABLE ведёт себя так, как будто транзакции выполняются по очереди, и полностью устраняет эти аномалии ценой возможных конфликтов и перезапусков транзакций.