Read Uncommitted¶

Read Uncommitted — это самый низкий уровень изоляции транзакций в системах управления базами данных (СУБД), при котором допускается чтение данных, изменённых, но ещё не зафиксированных (не подтверждённых) другими транзакциями. Данный уровень регламентирован стандартом SQL (ISO/IEC 9075) и характеризуется отсутствием блокировок при чтении, что обеспечивает максимальную производительность, но ценой целостности данных.

¶История и стандартизация

Понятие уровней изоляции транзакций было формализовано в 1992 году в стандарте SQL-92 (ANSI X3.135-1992). Разработчики стандарта выделили четыре уровня, упорядоченных по возрастанию строгости: Read Uncommitted, Read Committed, Repeatable Read и Serializable. Read Uncommitted был определён как уровень, предотвращающий только один из трёх классических аномалий — «грязное чтение» (dirty read) в терминологии стандарта, хотя на практике он её не исключает. Позднее, в 1995 году, в работе Х. Беренсона и др. «A Critique of ANSI SQL Isolation Levels» были уточнены определения аномалий и показано, что Read Uncommitted допускает все три основные аномалии: «грязное чтение», «неповторяющееся чтение» и «фантомное чтение».

¶Принцип работы

При уровне изоляции Read Uncommitted транзакция не устанавливает блокировки на чтение данных. Она может читать любые строки, даже если они в данный момент изменяются другой транзакцией, которая ещё не завершилась (не выполнила COMMIT или ROLLBACK). Запись данных при этом обычно выполняется с блокировками на уровне строк или страниц, чтобы предотвратить конфликты одновременной записи, но чтение этих блокировок игнорирует.

В большинстве реализаций СУБД (например, в Microsoft SQL Server) Read Uncommitted эквивалентен указанию подсказки NOLOCK в запросах. В PostgreSQL данный уровень изоляции технически не реализован как отдельный режим: при попытке установить Read Uncommitted он автоматически повышается до Read Committed, поскольку архитектура MVCC (многоверсионное управление конкурентным доступом) в PostgreSQL не позволяет читать незафиксированные данные без специальных расширений.

¶Аномалии, допускаемые уровнем

¶Грязное чтение (Dirty Read)

Транзакция A читает данные, которые были изменены транзакцией B, но ещё не зафиксированы. Если транзакция B впоследствии выполнит откат (ROLLBACK), то данные, прочитанные транзакцией A, окажутся несуществующими и могут привести к некорректным решениям.

Пример:

1. Транзакция B изменяет баланс счета с 1000 на 500 (не завершена).
2. Транзакция A читает баланс и получает 500.
3. Транзакция B откатывает изменения, баланс возвращается к 1000.
4. Транзакция A продолжает работу с неверными данными (500).

¶Неповторяющееся чтение (Non-repeatable Read)

Транзакция A читает одну и ту же строку дважды, но между чтениями другая транзакция B изменяет и фиксирует эту строку. В результате первое и второе чтения дают разные значения.

¶Фантомное чтение (Phantom Read)

Транзакция A выполняет запрос с условием (например, SELECT * FROM orders WHERE status = 'new'), а затем другая транзакция B вставляет новую строку, удовлетворяющую этому условию, и фиксирует её. При повторном выполнении того же запроса транзакция A получает дополнительную строку («фантом»).

¶Применение

Read Uncommitted используется в сценариях, где скорость и пропускная способность критически важны, а точность данных не является строгим требованием. Типичные области применения:

• Аналитические и отчётные системы — при построении приблизительных агрегатов (например, подсчёт общего количества записей, средних значений), где допустима погрешность в несколько процентов.
• Мониторинг и логирование — чтение текущего состояния системы без ожидания завершения транзакций записи.
• Поисковые системы — индексация и чтение данных, где временная несогласованность не влияет на конечный результат.
• Системы с высокой конкурентной нагрузкой — например, в социальных сетях или новостных лентах, где пользователь может видеть ещё не подтверждённые публикации.

¶Поддержка в СУБД

¶Критика и ограничения

Основной недостаток Read Uncommitted — риск получения недостоверных данных, что может привести к логическим ошибкам в приложениях. В системах, где целостность данных критична (финансовые операции, бронирование, учёт), использование этого уровня, как правило, запрещено на уровне архитектуры.

Кроме того, в некоторых реализациях (например, в SQL Server) подсказка NOLOCK может приводить к ошибкам времени выполнения, связанным с перемещением страниц данных (например, ошибка 601 «Could not continue scan with NOLOCK due to data movement»). В PostgreSQL и Oracle отсутствие поддержки Read Uncommitted компенсируется эффективной реализацией MVCC, которая позволяет достигать высокой производительности без риска грязного чтения.

¶Альтернативы

Для задач, где требуется высокая производительность, но недопустимо грязное чтение, применяются другие подходы:

• Snapshot Isolation (изоляция моментальных снимков) — транзакция видит состояние данных на момент своего начала, изменения других транзакций не видны до их фиксации.
• Read Committed — стандартный уровень, исключающий грязное чтение, но допускающий неповторяющееся и фантомное чтение.
• Read Committed Snapshot — вариант в SQL Server, использующий версионирование строк.

¶Источники

• ISO/IEC 9075-2:2016, Information technology — Database languages — SQL — Part 2: Foundation (SQL/Foundation).
• Berenson, H., Bernstein, P., Gray, J., Melton, J., O'Neil, E., O'Neil, P. (1995). A Critique of ANSI SQL Isolation Levels. Proceedings of the 1995 ACM SIGMOD International Conference on Management of Data.
• Gray, J., Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
• Microsoft SQL Server Documentation: Isolation Levels in the Database Engine.
• PostgreSQL Documentation: Chapter 13. Concurrency Control.