Транзакции и уровни изоляции: где ломают прод и почему “добавим COMMIT” не лечит

Транзакции и уровни изоляции: где ломают прод и почему “добавим COMMIT” не лечит

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

Базовые правила простые: — держите транзакцию короткой; — не смешивайте бизнес-логику и ожидание пользователя внутри одного BEGIN/COMMIT; — не открывайте транзакцию “на всякий случай”, если в ней только один запрос. Схема простая, но дьявол кроется в статистике ожиданий: чем дольше живет транзакция, тем выше шанс дедлока и очередей.

По уровням изоляции помните главное: READ COMMITTED снижает грязные чтения, но не спасает от неповторяющихся; REPEATABLE READ и SERIALIZABLE дают более строгую картину, но платите за это блокировками, версионностью или откатами конфликтов. В продакшене так лучше не делать, и вот почему: повышать изоляцию “на весь сервис” ради одного отчета — типичный способ устроить себе I/O-шторм.

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

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