Почему мультиверсионность мешает Read uncommited?

Question

deepseek-v3.2 · Accepted Answer

## Взаимосвязь мультиверсионности и уровня изоляции Read Uncommitted

Чтобы понять, почему **мультиверсионность** (Multi-Version Concurrency Control, MVCC) мешает реализации уровня изоляции **Read Uncommitted**, нужно разобраться в фундаментальных принципах обеих концепций и их противоречии.

### Суть MVCC и Read Uncommitted

**MVCC** — это механизм управления параллельным доступом, при котором для каждой строки данных хранится несколько версий (версии создаются при UPDATE/DELETE). Каждая транзакция видит **согласованный снимок** данных на момент своего начала. Это достигается за счёт:
- Хранения версий строк с метками времени/номерами транзакций
- Фильтрации версий для каждой транзакции по правилам видимости
- Отсутствия блокировок на чтение (читающие транзакции не блокируют пишущих)

**Read Uncommitted** — самый слабый уровень изоляции в SQL-стандарте. Его ключевая характеристика — возможность **чтения "грязных" данных** (Dirty Read): транзакция может видеть незафиксированные изменения других транзакций.

### Фундаментальное противоречие

MVCC по своей природе **несовместим** с чтением незафиксированных данных, потому что:

1. **MVCC строится на концепции согласованного снимка**
   В MVCC каждая транзакция работает с версиями данных, которые были **уже зафиксированы** на момент её начала. Система определяет видимость версий на основе статуса транзакций:

```sql
-- В MVCC-системе (например, PostgreSQL) даже при самом низком уровне изоляции
-- транзакция не увидит незафиксированные данные
BEGIN TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- Эта транзакция всё равно получит согласованный снимок
SELECT * FROM users WHERE id = 1;
```

2. **Механизм версионирования исключает доступ к "сырым" данным**
   В MVCC новые версии строк становятся доступными для других транзакций только после коммита. До этого они существуют в "буфере" изменений текущей транзакции, но не в основном хранилище версий.

3. **Архитектурное различие подходов**
   - Системы **без MVCC** (например, SQL Server по умолчанию) используют блокировки для изоляции. При Read Uncommitted снимаются блокировки на чтение, позволяя читать заблокированные данные
   - Системы **с MVCC** (PostgreSQL, Oracle, MySQL с InnoDB) вообще не используют блокировки для чтения, поэтому им нечего "ослаблять"

### Практические примеры

В **PostgreSQL** уровень READ UNCOMMITTED фактически работает как READ COMMITTED:
```sql
-- В PostgreSQL это идентичные уровни изоляции
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- Оба дадут одинаковый результат - без Dirty Reads
```

В **SQL Server** (без MVCC по умолчанию) разница есть:
```sql
-- Может читать незафиксированные данные
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM Orders;

-- Не читает незафиксированные данные  
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM Orders;
```

### Почему MVCC "мешает" Read Uncommitted

1. **Отсутствие механизма доступа к незафиксированным данным**
   MVCC-системы физически не предоставляют API для чтения незавершённых изменений. Все версии в хранилище помечены идентификатором транзакции и её статусом.

2. **Консистентность снимка данных**
   Архитектура MVCC гарантирует, что каждая транзакция видит консистентное состояние базы. Разрешение чтения незафиксированных данных нарушило бы эту гарантию на архитектурном уровне.

3. **Оптимизация производительности**
   MVCC оптимизирован для работы с версиями, а не с текущим "сырым" состоянием. Проверка статуса каждой транзакции для определения, можно ли показывать её изменения, добавила бы значительные накладные расходы.

### Исключения и нюансы

Некоторые СУБД с MVCC всё же эмулируют READ UNCOMMITTED, но с ограничениями:
- **MySQL/InnoDB**: READ UNCOMMITTED позволяет читать последнюю версию строки, даже если она незафиксирована, но это скорее исключение, нарушающее чистую модель MVCC
- **Oracle**: не поддерживает READ UNCOMMITTED вообще, предлагая только более строгие уровни изоляции

### Вывод

Мультиверсионность не просто "мешает" Read Uncommitted — она **фундаментально несовместима** с ним. MVCC проектировалась как альтернатива блокировкам, обеспечивающая высокую производительность без риска взаимоблокировок, но ценой отказа от возможности чтения незафиксированных данных. Это сознательный архитектурный выбор: лучше пожертвовать самым слабым уровнем изоляции, чем усложнять эффективную и масштабируемую систему управления версиями.

В современных СУБД эта "помеха" рассматривается как преимущество — разработчики вынуждены использовать более строгие уровни изоляции, что уменьшает вероятность ошибок, связанных с несогласованностью данных.

Почему мультиверсионность мешает Read uncommited?

Комментарии (1)

Взаимосвязь мультиверсионности и уровня изоляции Read Uncommitted

Суть MVCC и Read Uncommitted

Фундаментальное противоречие

Практические примеры

Почему MVCC "мешает" Read Uncommitted

Исключения и нюансы

Вывод