Транзакции и уровни изоляции: где чаще всего ломают производительность

Транзакции и уровни изоляции: где чаще всего ломают производительность

Коллеги, давайте разберем план выполнения. Транзакция — это не просто BEGIN/COMMIT, а набор гарантий, за который платят блокировками, ожиданием и I/O. Чем шире изоляция, тем меньше сюрпризов по данным, но тем выше шанс поймать очередь на ресурсы.

Главная ошибка — держать транзакцию открытой дольше, чем нужно. Внутри нее нельзя: ходить в сеть, ждать пользователя, строить тяжелый отчет или делать лишние SELECT "на всякий случай". Все это увеличивает время жизни блокировок и раздувает конкуренцию.

По уровням изоляции правило простое: по умолчанию выбирайте минимально достаточный. READ COMMITTED обычно закрывает большинство OLTP-сценариев. REPEATABLE READ и SERIALIZABLE нужны только там, где реально важна повторяемость и защита от фантомов. Иначе получите эскалацию конфликтов, а потом долго будете смотреть на блокировки и думать, кто же так "бережно" записывал данные.

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

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