Какие знаешь уровни изоляции транзакции

Уровень изоляции определяет, как транзакции могут взаимодействовать между собой, и насколько сильно могут пересекаться и мешать друг другу при параллельной работе. Иначе говоря, разные уровни изоляции допускают или не допускают разные аномалии при параллельной работе транзакций (про аномалии расскажем дальше).

Основные 4 уровня изоляции:

READ UNCOMMITTED

READ UNCOMMITTED - это самый слабый уровень изоляции, когда транзакция может видеть результаты других транзакций, даже если они ещё не закоммичены.

Он допускает:

- Грязное чтение

- Неповторяющееся чтение

- Фантомное чтение

По факту, на этом уровне изоляция отсутствует. Где-нибудь в аналитике больших данных такой уровень может ещё использоваться, где нам не так важна точность данных, но это достаточно редко.

READ COMMITTED

READ COMMITTED - на этом уровне транзакция может читать только те изменения в других параллельных транзакциях, которые уже были закоммичены.

Он предотвращает:

- Грязное чтение

Но он допускает:

- Неповторяющееся чтение

- Фантомное чтение

Такой уровень по умолчанию используется, например, в PostgreSQL и Oracle.

REPEATABLE READ

REPEATABLE READ - этот уровень означает, что пока транзакция не завершится, никто параллельно не может изменять или удалять строки, которые транзакция уже прочитала. Т. е. данные, которые я прочитал своей транзакцией, точно никто не изменит, пока я не завершу свою транзакцию (по крайней мере, в классическом понимании этого уровня с блокировками).

Он предотвращает:

- Неповторяющееся чтение

- Грязное чтение

Но он допускает:

- Фантомное чтение

Используется по умолчанию в MySQL.

SERIALIZABLE

SERIALIZABLE - самый жёсткий, но самый тяжёлый для БД и медленный для обработки запросов уровень.

Он блокирует любые действия, пока запущена транзакция - получается, транзакции идут строго одна за другой и максимально изолируются друг от друга.

Это достигается с помощью блокировки всей таблицы от любых взаимодействий с ней, но некоторые СУБД делают менее радикально - блокируют только те строки, которые задействует текущая транзакция или диапазон строк.

Предотвращает все аномалии:

- Неповторяющееся чтение

- Грязное чтение

- Фантомное чтение

Но страдает производительность из-за того, что транзакции не могут работать параллельно.

Зачем нам все эти уровни?

Почему не обойтись каким-нибудь самым безопасным SERIALIZABLE, который не допускает никаких аномалий, или каким-нибудь среднячком READ COMMITED?

Потому что в реальной жизни бизнесовые задачи бывают совсем разные: где-то нам важно сохранять максимальную целостность данных и изолировать транзакции так, чтобы они не пересекались друг с другом, т. к. при конфликте или ошибке цена будет велика, а где-то мы можем смириться с какими-то кейсами нестыковок в данных, но зато у нас будет производительность - мы сможем запускать больше транзакций одновременно.