<b>Транзакции и уровни изоляции: где ломается логика и начинается блокировка</b>

<b>Транзакции и уровни изоляции: где ломается логика и начинается блокировка</b>

Коллеги, давайте разберем план выполнения. Транзакция — это не магия «всё или ничего», а договор с СУБД: читаем, пишем и блокируем только в рамках выбранной изоляции.

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

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

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

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