Уровни изоляции в базах данных за 5 минут

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

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

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

• Read Uncommitted (минимальный уровень)

Транзакции вообще не изолированы. Видно изменения других транзакций даже до их коммита. Это может привести к dirty reads.

• Read Committed

Транзакция видит только закоммиченные данные. Dirty reads исключены, но non-repeatable reads остаются возможны.

• Repeatable Read

Транзакция работает с "замороженным снимком" базы на момент старта. Изменения других транзакций ей не видны. Реализация бывает через блокировки (shared locks) или MVCC (мультиверсии строк). Это убирает non-repeatable reads.

• Serializable

Максимальная строгость. Всё выглядит так, будто транзакции идут последовательно одна за другой. Для этого применяются жесткие блокировки вроде range/predicate locks.

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

👉 Java Portal