Транзакции и уровни изоляции: как не устроить дедлоки и «грязные» чтения

Транзакции и уровни изоляции: как не устроить дедлоки и «грязные» чтения

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

Базовые правила простые:
— держите транзакцию короткой: никаких запросов к API, файлов и долгих вычислений внутри;
— берите только те строки, которые реально меняете, иначе блокировки расползутся по таблице;
— не смешивайте чтение отчета и массовый апдейт в одной транзакции без причины;
— если нужен повторяемый результат чтения, заранее проверьте, выдержит ли это нагрузку.

С уровнями изоляции та же история: чем выше изоляция, тем меньше сюрпризов и тем выше цена. Read Committed обычно закрывает большинство рабочих сценариев. Repeatable Read и Serializable нужны не «на всякий случай», а когда бизнес-логика действительно ломается от фантомов или повторного чтения. И да, в продакшене так лучше не делать, если не понимаете, какие именно блокировки появятся.

Если видите рост wait time, сначала смотрите не на индексы, а на конкуренцию транзакций. Схема простая, но дьявол кроется в статистике: длинные транзакции, широкие апдейты и лишний уровень изоляции почти всегда дороже, чем аккуратный код и явный контроль границ.

Золотое правило: сначала мониторинг, потом индексы. Сначала поймите, где транзакция держит ресурсы, и только потом повышайте изоляцию или переписывайте запрос.