🟢 Junior Level

Read Uncommitted — это самый низкий уровень изоляции транзакций. При этом уровне одна транзакция может видеть изменения, внесённые другой транзакцией, даже если она ещё не завершена (не сделан COMMIT).

Главная проблема — Dirty Read (Грязное чтение)

Представьте ситуацию:

1. Транзакция А изменила баланс с 100 на 500
2. Транзакция Б прочитала баланс и видит 500
3. Транзакция А отменилась (ROLLBACK) — баланс вернулся к 100
4. Транзакция Б работала с несуществующими данными (500)

Когда используется

Практически никогда в реальных приложениях. Иногда для быстрой приблизительной статистики, когда точность не важна.

Важно

В PostgreSQL и Oracle этого уровня фактически нет — если вы его установите, база автоматически переключит вас на Read Committed.

---

🟡 Middle Level

Основные характеристики

• Аномалии: Допускает все три — Dirty Read, Non-repeatable Read, Phantom Read
• Производительность: Теоретически самый быстрый уровень, так как нет overhead на изоляцию
• Блокировки: Чтение не блокируется записью, запись не блокируется чтением

Сценарий Dirty Read подробно

Время    Транзакция А               Транзакция Б (Read Uncommitted)
T1       BEGIN;                     
T2       UPDATE accounts SET        
         balance = 500 WHERE id = 1;
T3                                    SELECT balance FROM accounts
                                      WHERE id = 1; -- Видит 500!
T4       ROLLBACK;                  
T5                                    Работает с балансом 500,
                                      но реально он 100

Почему Б видит 500? На Read Uncommitted СУБД не создаёт snapshot. Чтение идёт напрямую из текущей версии строки, даже если транзакция-автор ещё не закоммитила.

Почему это опасно

• Финансы: Решение о кредите на основе неподтверждённого баланса
• Склады: Бронирование товара, который ещё не поступил
• Целостность: Можно увидеть данные, нарушающие constraints (например, отрицательный баланс, который будет откачен)

SQL Server NOLOCK

В SQL Server на этом уровне часто используют хинт WITH (NOLOCK) в SELECT-запросах:

SELECT * FROM accounts WITH (NOLOCK);

Это позволяет читать данные без установки shared locks, что даёт ту же семантику, что и Read Uncommitted.

Особенности в PostgreSQL и Oracle

PostgreSQL: Уровень Read Uncommitted физически отсутствует. Команда SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED молча переводит на Read Committed.

Oracle: Также не позволяет опуститься ниже Read Committed. Гарантирует отсутствие грязного чтения архитектурно.

---

🔴 Senior Level

Почему Read Uncommitted практически не используется

Architecture Perspective

В современных MVCC-based системах (PostgreSQL, Oracle) dirty read prevention built-in на архитектурном уровне:

• Readers always see committed versions only
• Uncommitted changes create new tuple versions not visible to others
• No additional overhead to prevent dirty reads — it’s free

When Read Uncommitted Might Be Acceptable

1. Approximate analytics: “Сколько примерно заказов сегодня?” — точность до 1-2% не критична
2. Health checks / monitoring: Быстрая проверка состояния без гарантии точности
3. Development/debugging: Временное использование для investigation

Hidden Costs of Read Uncommitted

Даже несмотря на отсутствие overhead на isolation:

• Data corruption risk: Application logic может принять решения на основе phantom data
• Cascading errors: Wrong data → wrong decisions → more wrong data
• Debugging nightmare: Intermittent bugs, hard to reproduce

Implementation Details в разных СУБД

SQL Server:

• Read Uncommitted = NOLOCK = чтение без shared locks
• Может читать “in-flight” data из uncommitted pages
• Risk of allocation order scans missing/miscounting rows

PostgreSQL:

• Автоматически elevation до Read Committed
• На Read Committed: каждый оператор видит snapshot на момент начала оператора
• Zero overhead для prevention dirty reads благодаря MVCC

MySQL/InnoDB:

• Поддерживает Read Uncommitted буквально
• Но undo log всё равно хранит committed versions
• Minor overhead savings vs Read Committed

Production Recommendation

В большинстве production-систем Read Uncommitted не нужен. Исключения: approximate dashboards (графики с допустимой погрешностью), internal monitoring tools.

Alternative Approaches

Вместо Read Uncommitted для performance:

1. Read Committed с query optimization: Правильные индексы дают больший выигрыш
2. Read replicas: Offload reporting queries к replica
3. Materialized views: Pre-computed aggregates
4. Caching layer: Redis/Memcached для approximate data

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Read Uncommitted — самый низкий уровень изоляции, допускает все 3 аномалии
• Главная проблема — Dirty Read: чтение незакоммиченных данных, которые могут быть откачены
• В PostgreSQL и Oracle этого уровня нет — автоматически elevation до Read Committed
• Практически не используется в production, кроме approximate analytics и monitoring
• SQL Server использует хинт WITH (NOLOCK) для dirty reads
• Dirty read особенно опасен: решения принимаются на основе данных, которых «никогда не существовало»

Частые уточняющие вопросы:

• Почему PostgreSQL не поддерживает Read Uncommitted? — MVCC architecture: dirty read prevention бесплатная
• Когда Read Uncommitted допустим? — Approximate dashboards, health checks, development/debugging
• Что видит транзакция на Read Uncommitted? — Незакоммиченные изменения других транзакций
• Чем Read Uncommitted отличается от Read Committed? — RC не допускает dirty reads

Красные флаги (НЕ говорить):

• “Read Uncommitted быстрее Read Committed” — в MVCC системах разницы нет
• “Можно использовать для финансовых отчётов” — недопустимый риск corrupted data
• “NOLOCK = безопасный способ чтения” — NOLOCK может читать дубликаты и пропускать строки

Связанные темы:

• [[2. Какие уровни изоляции транзакций существуют]]
• [[7. Что такое грязное чтение (Dirty Read)]]
• [[4. Что такое Read Committed]]