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

Уровни изоляции транзакций в SQL

В SQL стандарт определяет четыре уровня изоляции транзакций, которые регулируют видимость изменений между параллельными транзакциями и предотвращают определенные аномалии чтения/записи. Эти уровни являются фундаментальной концепцией систем управления базами данных (СУБД), обеспечивающей баланс между согласованностью данных и производительностью.

Основные уровни изоляции (от самого слабого к самому строгому)

1. READ UNCOMMITTED (Чтение незафиксированных данных)

Это самый низкий уровень изоляции. Транзакция видит незафиксированные изменения других параллельных транзакций («грязные» данные). Это может приводить к следующим аномалиям:

• Грязное чтение (Dirty Read): чтение данных, которые впоследствии могут быть откатаны другой транзакцией.
• Неповторяющееся чтение (Non-repeatable Read)
• Фантомное чтение (Phantom Read)

Пример:

-- Сессия 1
BEGIN TRANSACTION;
UPDATE users SET balance = 1000 WHERE id = 1; -- Не коммитит

-- Сессия 2 (уровень READ UNCOMMITTED)
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT balance FROM users WHERE id = 1; -- Увидит 1000, хотя транзакция 1 ещё не завершена

2. READ COMMITTED (Чтение зафиксированных данных)

Стандартный уровень во многих СУБД (например, PostgreSQL по умолчанию). Транзакция видит только данные, зафиксированные другими транзакциями на момент выполнения каждого оператора SELECT. Предотвращает грязное чтение, но возможны:

• Неповторяющееся чтение: две выборки одного ряда в рамках одной транзакции могут показать разные данные, если другая транзакция изменила и зафиксировала этот ряд между выборками.
• Фантомное чтение.

Реализация часто использует механизм блокировок строк или версионирование данных (MVCC).

-- Сессия 1
BEGIN TRANSACTION;
UPDATE users SET balance = 2000 WHERE id = 1;
COMMIT; -- Фиксируем

-- Сессия 2
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT balance FROM users WHERE id = 1; -- Увидит зафиксированное значение 2000

3. REPEATABLE READ (Повторяемое чтение)

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

• Фантомные чтения: появление новых строк, удовлетворяющих условию запроса, которые были добавлены другими транзакциями.

В MySQL (InnoDB) этот уровень по умолчанию обеспечивает полную консистентность снимка данных (snapshot) за счёт MVCC и предотвращает даже фантомные чтения.

-- Сессия 1
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT balance FROM users WHERE id = 1; -- Читает значение

-- Сессия 2
UPDATE users SET balance = balance + 500 WHERE id = 1;
COMMIT;

-- Сессия 1 (та же транзакция)
SELECT balance FROM users WHERE id = 1; -- Значение останется прежним, как при первой выборке
COMMIT;

4. SERIALIZABLE (Сериализуемый)

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

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
SELECT * FROM users WHERE balance > 1000; -- Блокирует диапазон для предотвращения вставок
-- Другие транзакции не могут вставить или изменить строки, попадающие под условие balance > 1000
COMMIT;

Аномалии, предотвращаемые уровнями изоляции

* В некоторых СУБД (например, MySQL/InnoDB) предотвращает и фантомные чтения.

Практическое применение и выбор уровня

Выбор уровня зависит от требований приложения:

• READ UNCOMMITTED: почти не используется, только для агрегационных аналитических запросов, где точность не критична.
• READ COMMITTED: оптимален для большинства OLTP-систем (онлайн-обработка транзакций), где важна актуальность данных и производительность.
• REPEATABLE READ: необходим для финансовых операций, отчётов, где требуется стабильный снимок данных на протяжении всей транзакции.
• SERIALIZABLE: применяется для критически важных операций (например, расчёт итоговой суммы с учётом всех зависимых строк), где любая аномалия недопустима. Влечёт серьёзные накладные расходы.

В PostgreSQL реализация основана на MVCC (Multi-Version Concurrency Control), а в MySQL (InnoDB) также используется MVCC, что обеспечивает эффективную работу строгих уровней изоляции без блокировок читающих транзакций. Важно помнить, что поведение может отличаться в разных СУБД, поэтому всегда нужно сверяться с документацией конкретной системы.