advanced
Isolation levels
Выбирайте isolation по anomaly tolerance, contention, latency и correctness requirements.
Уровни изоляции определяют, какие аномалии параллелизма транзакция может наблюдать. Стандартные уровни SQL обменивают гарантии корректности на contention и латентность.
| Уровень | Dirty read | Non-repeatable read | Phantom read | |---------|------------|---------------------|--------------| | Read uncommitted | Возможен | Возможен | Возможен | | Read committed | Нет | Возможен | Возможен | | Repeatable read | Нет | Нет | Возможен* | | Serializable | Нет | Нет | Нет |
*В PostgreSQL repeatable read также блокирует многие phantoms через MVCC snapshot; настоящий serializable использует SSI.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- default в PostgreSQL
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; -- строжайший, возможны retry
Read committed — типичный default: каждый statement видит зафиксированные данные на момент его начала. Repeatable read держит snapshot на всю транзакцию — стабильное чтение, но write skew возможен без serializable или явных locks. Serializable обнаруживает конфликты и может прервать транзакцию — приложение должно повторять.
На интервью: назовите аномалию (dirty, non-repeatable, phantom, write skew) и выберите минимальную изоляцию, которая её запрещает.
Типовые ошибки: считать, что `REPEATABLE READ` закрывает все гонки; игнорировать retry при serialization failure; длинные аналитические чтения на production OLTP без snapshot/export; default различается между движками (MySQL RR ≠ PostgreSQL RR).
Компромисс — между строгой корректностью и частотой abort/retry и contention locks: не включайте serializable везде; подгоняйте под допустимость устаревших чтений и lost updates в продукте.
Чеклист:
- Назовите аномалию, которую нужно предотвратить.
- Укажите default движка и выбранный уровень.
- Опишите политику retry при serialization failure.
- Отделите snapshot для отчётности от изоляции OLTP.
- Свяжите выбор уровня с конкретным пользовательским багом.