Кратко — определения аномалий, затем по уровням и практические последствия.
Аномалии
- Грязное чтение (dirty read): транзакция читает данные, записанные другой транзакцией, которая ещё не зафиксирована; если та откатится — прочитанные данные «ложны».
- Неповторяющееся чтение (non‑repeatable read): в одной транзакции два чтения одной строки дают разные значения из‑за коммита другой транзакции между чтениями.
- Фантом (phantom): два запроса с одинаковым предикатом возвращают разные множества строк (появились/исчезли строки), т.е. нарушается согласованность результата выборки по предикату.
- (Дополнительно) Write skew — аномалия при snapshot isolation, когда две транзакции читают перекрёстно и оба коммитят нетривиально согласующиеся изменения.
Уровни изоляции (SQL standard) — что допускают
- Read Uncommitted
- Допускает: грязное чтение, неповторяющееся чтение, фантомы.
- Комментарий: практически отсутствует изоляция; очень высокая конкуренция, но неприменим для корректности.
- Read Committed
- Запрещает: грязные чтения.
- Допускает: неповторяющееся чтение и фантомы.
- Комментарий: каждое чтение видит последнее зафиксированное состояние; хороший компромисс для многих OLTP, но неверна для требований повторяемости.
- Repeatable Read (стандарт):
- Запрещает: грязные чтения и неповторяющееся чтение.
- Может допускать: фантомы (стандартный Repeatable Read не гарантирует отсутствие фантомов).
- Примечание по СУБД: реализация различается — MySQL InnoDB традиционно использует механизмы (next‑key locks) чтобы предотвращать фантомы; PostgreSQL/Oracle часто дают поведение, эквивалентное snapshot isolation (см. ниже), которое предотвращает неповторяемые чтения и фантомы на уровне снимка, но допускает другие аномалии (write skew).
- Serializable
- Запрещает: грязные чтения, неповторяющиеся чтения и фантомы — обеспечивает эквивалент поведения при последовательном выполнении транзакций.
- Комментарий: наиболее строгий уровень; чаще всего достигается за счёт блокировок или обнаружения конфликтов и откатов транзакций.
Реальные СУБД — важные отличия
- PostgreSQL:
- Read Committed — statement‑level snapshot (нет грязных чтений; возможны неповторяющиеся чтения/фантомы).
- Repeatable Read — snapshot isolation (транзакция видит стабильный снимок); предотвращает неповторяемые чтения и классические фантомы в смысле видимости снимка, но допускает write skew. Serializable — обеспечивает истинную сериализацию (иногда путём отката транзакций при обнаружении конфликтов).
- MySQL InnoDB:
- REPEATABLE READ с MVCC + gap/next‑key locks часто предотвращает фантомы; реализация зависит от настроек и запросов (FOR UPDATE/LOCK IN SHARE MODE).
- Oracle:
- Использует read consistency (snapshot для чтений); Read Committed и Serializable поведение отличается от SQL‑стандарта.
Влияние на дизайн приложения — практические рекомендации
- Выбор уровня зависит от требований корректности vs. производительности:
- Если нужна формальная корректность при конкуренции — использовать Serializable (или эквивалент) и быть готовым к повышенному числу откатов/повторных попыток.
- Для большинства OLTP задач Read Committed — разумный компромисс (избегает грязных чтений, хорошая пропускная способность).
- Если нужно, чтобы повторные чтения в одной транзакции были стабильными — использовать Repeatable Read / snapshot isolation; учитывать возможность write skew.
- Стратегии проектирования:
- Минимизируйте длительность транзакций (короткие транзакции снижают конфликты).
- При необходимости силовых блокировок используйте SELECT ... FOR UPDATE / explicit locks для предотвращения фантомов/конфликтов на нужных строках.
- Используйте уникальные ограничения и внешние ключи для защиты от логических фантомов; дополнительно проверяйте invariant‑ы в транзакции (и перезапускайте при необходимости).
- Применяйте optimistic concurrency control: version/timestamp поля + проверка при коммите (если конфликт — retry).
- Для распределённых систем/маятниковых проблем: проектируйте idempotent‑операции и ретраи, чтобы обработать возможные откаты при Serializable.
- Тестируйте под нагрузкой: симулируйте конкуренцию, чтобы выявить реальные аномалии в выбранной СУБД.
Коротко: чем выше уровень изоляции — тем менее возможны аномалии, но тем выше стоимость (блокировки/откаты/меньшая параллельность). Выбирайте уровень исходя из требований корректности и проектируйте транзакции/ретраи и блокировки там, где сильная изоляция невозможна или слишком дорогая.