Транзакции и уровни изоляции: где ломается логика и растёт блокировка

Транзакции и уровни изоляции: где ломается логика и растёт блокировка

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

Базовый разбор простой:
— READ COMMITTED: меньше блокировок, но возможны «грязные» сюрпризы между запросами в рамках одной бизнес-операции;
— REPEATABLE READ: читаете стабильнее, но удерживаете больше ресурсов;
— SERIALIZABLE: максимальная строгость, но цена — конкуренция, блокировки и падение параллелизма.
Золотое правило: сначала мониторинг, потом индексы. Смотрите не только на запрос, но и на время удержания транзакции.

Типовая ошибка — смешивать чтение и запись без явной стратегии. Если нужен снимок данных, лучше один короткий SELECT в начале, а изменения делать отдельным, коротким блоком. Если операция идемпотентна, это часто дешевле, чем держать тяжёлую изоляцию «на всякий случай». Посмотрим, что тут с I/O в реальности: часто проблема не в самом уровне изоляции, а в том, что транзакция ждёт медленный диск или внешний сервис.

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