Коротко по каждому уровню, какие аномалии возможны, примеры, как предотвращать и какие компромиссы по производительности.
Определения аномалий
- Dirty read — чтение данных, записанных транзакцией, которая ещё не зафиксирована и может откатиться.
Пример: $T1:$ записал $x=1$ (не committed); $T2:$ прочитал $x=1$; затем $T1$ откатил — $T2$ прочитал «грязное» значение.
- Non-repeatable read — одна и та же строка даёт разные значения при повторных чтениях внутри одной транзакции из‑за коммита другой транзакции.
Пример: $T1:$ прочитал $x=1$; $T2:$ обновил и закоммитил $x=2$; $T1:$ прочитал снова — $x=2$.
- Phantom read — повторный запрос множества строк даёт другой набор строк (появились/пропали строки, удовлетворяющие предикату).
Пример: $T1:$ сделал $\text{SELECT * FROM table WHERE cond}$ — 5 строк; $T2:$ вставил новую строку, закоммитил; $T1:$ повторил SELECT — теперь 6 строк.
Уровни изоляции (стандарт SQL, с краткими примерами и мерами предотвращения)
- READ UNCOMMITTED
- Что допускает: dirty read, non-repeatable read, phantom.
- Почему: минимальные блокировки, читаются неподтверждённые изменения.
- Предотвращение (если нужно): явные блокировки (например, $\text{SELECT FOR UPDATE}$) или повышение уровня изоляции.
- Компромисс: максимальная параллельность и минимальная задержка чтений, но риск некорректных данных.
- READ COMMITTED
- Что допускает: non-repeatable read, phantom; предотвращает dirty read.
- Почему: чтения видят только закоммиченные изменения, но разные чтения могут видеть разные коммиты других транзакций.
- Предотвращение non-repeatable/phantom: использовать REPEATABLE READ/SERIALIZABLE или явные замки на чтение/набор (predicate locks / SELECT ... FOR UPDATE).
- Компромисс: хороший баланс для OLTP — меньше «грязных» чтений, высокая конкурентность, но чтения не стабильны внутри транзакции.
- REPEATABLE READ (стандартно: предотвращает non-repeatable reads, но может допускать фантомы)
- Что допускает: по стандарту — phantom; не допускает dirty и non-repeatable reads.
- Практика DBMS: реализации различаются — например, InnoDB (MySQL) с next‑key locks блокирует фантомы; многие MVCC-системы (PostgreSQL REPEATABLE READ / snapshot) дают стабильный снапшот и не показывают изменённые/новые строки в рамках снапшота, но могут иметь другие аномалии (write skew) при отсутствии полной сериализации.
- Предотвращение фантомов: predicate/next‑key locks, или переход на SERIALIZABLE (или SSI в PostgreSQL).
- Компромисс: более строгая консистентность для повторных чтений, больше блокировок/контеншна или затрат на поддержание снапшотов.
- SERIALIZABLE
- Что допускает: по определению — никаких dirty/non-repeatable/phantom; поведение эквивалентно некоторой последовательной (serial) интерпретации транзакций.
- Как достигается: строгая двухфазная блокировка (2PL), predicate locks, или оптимистические механизмы с проверкой/откатом (SSI, OCC).
- Предотвращение: уровень сам по себе предотвращает все перечисленные аномалии; реализации могут отвергать (абортировать) транзакции при конфликте (не блокировать бесконечно).
- Компромисс: наибольшая потеря параллелизма, увеличение числа блокировок/ожиданий и риска дедлоков, либо увеличение числа принудительных откатов и повторных попыток у оптимистичных схем.
Способы предотвращения и их компромиссы (обобщение)
- Блокировки (S/X, next‑key, predicate locks): надёжно предотвращают аномалии; увеличивают задержки и риск дедлоков; хороши при высоких требованиях к согласованности, хуже при высокой конкуренции на записи.
- MVCC (snapshot isolation): читатели не блокируют писателей — хорошие чтения с малой задержкой; препятствует dirty/non-repeatable reads внутри снапшота, но стандартная snapshot isolation может допускать write‑skew (не полная сериализация) и требует дополнительных механизмов (SSI) для полной сериализуемости; требует больше дискового пространства и GC (cleanup).
- Оптимистическая проверка / OCC: хорошие для транзакций с низким уровнем конфликтов; при конфликтах — откаты и повторные попытки, что может быть дорого при высокой конкуренции.
- Явные блокировки у приложения (advisory locks): даёт контроль, но усложняет код и может понизить параллелизм.
Короткие рекомендации
- Для большей пропускной способности чтений и типичного OLTP: READ COMMITTED или MVCC‑REPEATABLE (снэпшот) часто оптимальны.
- Для критичной целостности — используйте SERIALIZABLE или явную блокировку/контролируемые транзакции; будьте готовы к снижению параллелизма и к ретраям при конфликте.
- Учтите различия реализаций СУБД (MySQL/InnoDB, PostgreSQL, Oracle): поведение REPEATABLE READ и способы предотвращения фантомов/write‑skew могут отличаться.
Если нужно, могу привести конкретные пошаговые примеры (с транзакциями) для каждого уровня или описать поведение в конкретной СУБД.