Транзакции базы данных для атомарных записей — как избежать полузаписанных данных

Что такое «полузаписанные» записи и почему они появляются

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

Пример: оформление заказа должно (1) создать запись заказа, (2) зарезервировать товар и (3) зафиксировать попытку оплаты. Если строка заказа создана, но обновление инвентаря провалилось, у вас есть заказ, который нельзя отправить. Если товар зарезервирован, а запись платежа отсутствует, служба поддержки видит, что товар исчез, но нет соответствующего дохода.

Такие несогласованности порождают баги, которые кажутся случайными:

• отсутствующие строки (заказ есть, а строк товаров нет)
• несоответствие итогов (сумма счёта не совпадает со строками)
• сиротские записи (платёж ссылается на несозданный заказ)
• дублированные записи (повтор создаёт второй заказ)
• «застрявшие» состояния (статус говорит «оплачено», но остальные данные не подтверждают это)

Пользователи ощущают это как критичную путаницу: регистрация, после которой показывают «Добро пожаловать», но позже войти нельзя; письмо с подтверждением заказа c пустым заказом; или платёж, который кажется успешным, но подписка не появляется.

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

Это особенно характерно для прототипов, сгенерированных ИИ: они обычно ориентированы на «радостный» сценарий. Краевые случаи вроде частичных отказов, повторов и очистки часто отсутствуют, поэтому операции, которые должны быть атомарными, превращаются в цепочку независимых запросов без плана отката.

Когда стоит использовать транзакцию (а когда нет)

Используйте транзакцию, когда одно действие пользователя создаёт или изменяет данные в нескольких местах, и «полузавершённое» состояние неприемлемо. Цель проста: либо все связанные изменения сохраняются, либо ни одно из них.

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

Они также нужны, когда изменения должны провалиться вместе из‑за денег или лимитов: остатки на складе, балансы аккаунтов, кредиты и использование квот. Если одно обновление произойдёт без другого, вы можете перепродать, дважды списать деньги или позволить пользователям превысить лимиты.

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

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

Признаки, что вам, вероятно, нужны транзакции (или более строгие): регулярные скрипты очистки после ошибок, тикеты поддержки «вижу на одном экране, но не на другом», дашборды, которые расходятся из‑за отсутствующих строк, и код, где сохранения разбросаны по разным хелперам.

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

Транзакции простыми словами: commit, rollback, atomic

Транзакция — это защитная оболочка вокруг набора записей в базу. Она превращает «сохранить эти 3 вещи» в одно действие «всё или ничего».

«Атомарно» значит: либо все изменения из группы сохраняются, либо ни одного. Нет среднего состояния, где часть строк есть, а часть нет.

Подумайте о чекауте: (1) создать заказ, (2) зарезервировать товар, (3) зафиксировать попытку оплаты. Без транзакции падение между шагами может оставить заказ, который выглядит реальным, но не имеет зарезервированных товаров, или зарезервированные товары без заказа. С транзакцией база рассматривает эти шаги как единицу.

Термины, которые вы увидите в коде и логах:

• Begin: начать транзакцию. Изменения временные до конца.
• Commit: сделать постоянным. Все изменения применяются одновременно.
• Rollback: отменить. БД отбрасывает всё, что сделано с момента Begin.

Commit и rollback — два чистых завершения. Если приложение может завершиться раньше (ошибка, таймаут, провал валидации), важно явно знать, чем закончилась транзакция.

Одно предложение об изоляции

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

Если запомнить одно правило: группируйте связанные вставки и обновления, которые должны выполниться вместе, и не запускайте сайд‑эффекты (письма, вебхуки, фоновые задачи) до коммита.

Пошагово: обернуть многошаговую запись в одну транзакцию

Полузаписи появляются, когда ранний шаг успешен (например, создание строки), а поздний шаг — нет (например, обновление баланса). Решение — рассматривать весь набор изменений как одну единицу работы.

Начните с определения границы: всё, что должно быть истинным вместе, помещайте в транзакцию. Например, «создать заказ + зарезервировать товар + записать intent платежа» должно либо полностью выполниться, либо не выполниться вовсе.

Надёжный поток выглядит так:

• Начать транзакцию до первой вставки/обновления в единице работы.
• Выполнять операторы в безопасном порядке (сначала родительская запись, затем дочерние, затем производные обновления).
• После каждого критического оператора проверять, что получили ожидаемое (количество строк, возвращённый id, ограничения).
• Если любой шаг провалился, немедленно остановиться и откатить.
• Закоммитить только когда все шаги успешны, затем вернуть один понятный ответ об успехе.

Вот форма в псевдокоде:

BEGIN;

-- 1) Create parent
INSERT INTO orders(...) VALUES(...) RETURNING id;

-- 2) Create children
INSERT INTO order_items(order_id, ...) VALUES (...);

-- 3) Update derived state
UPDATE inventory SET reserved = reserved + 1 WHERE sku = ? AND available \u003e 0;

COMMIT;

Две детали решают всё.

Во‑первых, не проглатывайте ошибки. Если шаг 3 обновил 0 строк, воспринимайте это как сбой, поднимайте ошибку и откатывайте.

Во‑вторых, не отправляйте ответ об успехе до завершения COMMIT. «OK» до коммита — это путь к частичным результатам, представляемым как «успех».

Если вы унаследовали код, сгенерированный ИИ, следите за «фейковыми» транзакциями, где каждый запрос открывает своё соединение. Код может выглядеть как транзакционный, но запросы фактически выполняются на разных сессиях.

Обработка ошибок: явные пути отката и понятные ошибки

Полузаписи часто происходят из‑за отношения «ошибка — это кто‑то другой». Решите заранее, что считается ошибкой, и сделайте все пути ошибок очевидными в коде.

Откатывайте не только при падениях. Откатывайте при исключениях (таймауты, ошибки ограничений, дедлоки), при неудачных проверках (обновление затронуло 0 строк, когда должно было 1), при валидации, зависящей от текущего состояния (например, «у пользователя уже есть активная подписка»), или при зависимых записях, возвращающих неожиданные значения.

Затем делайте откат явным. Избегайте паттернов вроде «catch и игнорировать» или возвращать false без очистки. Простой шаблон поддержит честность:

begin transaction
try:
  write A
  write B
  verify row counts
  commit
  return success
except error:
  rollback
  log safe context
  return clear failure
finally:
  close connection

Понятные ошибки важны. Вызывающий должен знать, что делать дальше («попробуйте снова» vs «некорректный ввод»), но сообщение не должно раскрывать секреты вроде SQL‑текста, токенов или переменных окружения. Практический подход — короткая причина плюс внутренний id ошибки, который можно найти в логах.

Никогда не оставляйте транзакцию открытой. Открытые транзакции могут блокировать строки, мешать другим пользователям и вызывать странные ошибки в последующих запросах. Всегда коммитьте или откатывайте, и всегда закрывайте соединение (или возвращайте его в пул) в блоке finally.

Логируйте достаточно, чтобы воспроизвести проблему, не сливая личные данные: имя операции (signup, checkout), релевантные id, количество строк и тип ошибки. Одна распространённая ошибка в кодовых базах, сгенерированных ИИ, — поймать ошибку, вернуть «успех» и оставить базу в двух версиях реальности.

Повторы и идемпотентность: безопасность при таймаутах

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

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

Идемпотентность означает, что повторный одинаковый запрос даёт тот же результат. Общий паттерн — требовать idempotency key (случайный ID от клиента) и сохранять его вместе с итогом. При повторе вы смотрите этот ключ и возвращаете оригинальный результат вместо повторного выполнения всего потока.

Практические способы сделать повторы безопасными:

• Добавьте уникальные ограничения, отражающие бизнес‑правила (один профиль на пользователя, одна подписка на пользователя в рамках рабочего пространства).
• Сохраните idempotency key с уникальным индексом и положите рядом id созданной записи.
• Используйте upsert там, где это соответствует правилам бизнеса (создать, если отсутствует, иначе переиспользовать существующую строку).
• Рассматривайте «unique constraint violation» как нормальный результат повтора: выберите существующую строку и верните её.
• Делайте внешние сайд‑эффекты (платежи, письма) тоже идемпотентными.

Пример: запрос на чекаут таймаутит сразу после коммита в базе, но до того, как ответ дошёл до браузера. При повторе с уникальным ограничением по (user_id, cart_id) и сохранённым idempotency key с payment_intent_id второй запрос вернёт тот же заказ и не создаст вторую оплату.

Советы по дизайну: держите транзакции малыми и сайд‑эффекты отдельными

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

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

Держите транзакцию сфокусированной

Распространённая ошибка — использовать транзакцию как общий «try/catch» для всего, что может пойти не так. Оставляйте вне её несвязанные действия.

Правила‑памятки:

• Помещайте в транзакцию только чтения и записи, которые должны выполниться вместе.
• Избегайте вызовов внешних сервисов, пока транзакция открыта.
• Не смешивайте медленные запросы или большие батчи с пользовательскими записями в одной транзакции.
• Делайте кодовую дорожку простой для понимания (одна точка входа, один commit).

Отделяйте сайд‑эффекты от изменений данных

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

Более безопасный паттерн: сохранить данные, закоммитить, затем запустить сайд‑эффекты.

Если нужна высокая надёжность, сохраняйте «outbox» запись в рамках той же транзакции (например, «отправить приветственное письмо пользователю 123»). После коммита воркер читает outbox и выполняет сайд‑эффект. При ошибке его можно безопасно повторить, не портя основные записи.

Частые ошибки, которые всё ещё приводят к полузаписям

Многие баги с полузаписанными данными не из‑за отсутствия транзакции. Они случаются, когда транзакция используется так, что тихо ломает гарантию «всё или ничего».

Классическая ошибка — сохранить «основную» запись, закоммитить, и только потом создавать обязательные связанные строки (аудит‑лог, profile, запись в join‑таблице). Если второй шаг провалится, вы получите запись, которая в одной таблице выглядит валидной, но без требуемых компаньонов.

Ещё одна распространённая проблема — обработка ошибок, которая пропускает очистку. Транзакция может быть открыта корректно, но одна ветка вернёт результат раньше (или бросит внутри колбека) без отката. В зависимости от стека это может оставить соединение в некорректном состоянии или привести к неожиданным коммитам.

Паттерны ошибок, часто встречающиеся в коде, сгенерированном ИИ:

• Поймать ошибку, залогировать и всё равно вернуть «успех».
• Делать вызов стороннего API (email, платежи, загрузки) пока транзакция открыта, и медленная сеть держит блокировки.
• Смешивать клиентов БД, так что одна запись выполняется на другом соединении и не входит в ту же транзакцию.
• Повторять запрос без идемпотентности, что создаёт дубликаты после таймаута.

Пример: поток регистрации вставляет в users, затем в user_profiles, затем в org_members. Если вставка профиля проваливается, а пользователь уже закоммитился, следующая попытка регистрации может столкнуться с «email уже существует», и пользователь останется в подвешенном состоянии.

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

Быстрые проверки перед релизом

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

Короткий тест на здравый смысл — проследите соединение. Каждый запрос, который должен проваливаться или проходить вместе, должен выполняться на одной и той же сессии/соединении. Это частая ошибка в коде, сгенерированном ИИ: один хелпер использует pooled connection, другой открывает новое, и транзакция покрывает только часть работы.

Короткий чек‑лист перед релизом:

• Определите единицу работы в одном предложении и оберните только её в одну транзакцию.
• Убедитесь, что все связанные записи используют одно и то же соединение/объект сессии от Begin до Commit.
• Сделайте пути ошибок скучными: при любой ошибке — rollback, вернуть понятную ошибку и остановиться.
• Добавьте ограничения, которые делают повторы безопасными (уникальные ключи на «один на пользователя», idempotency key для запросов).
• Держите сайд‑эффекты вне транзакции: отправка писем, вебхуков и загрузок — только после коммита (или в очередь).

Затем проведите один «сломайте это» тест: намеренно вызовите ошибку на шаге 2 из 3 (например, нарушьте ограничение на третьей таблице). После провала запроса проверьте базу. Вы должны увидеть ноль новых строк, а не «какие‑то строки без своих компаньонов».

Пример: поток регистрации, который пишет в 3 таблицы

Представьте регистрацию, которая должна записать три строки:

• users (email, password_hash)
• profiles (user_id, display_name)
• subscriptions (user_id, plan)

Если выполнять их как три отдельных запроса, можно получить полузаписи. Например, строка в users создана, а вставка в profiles провалилась из‑за слишком длинного display_name или отсутствия обязательного поля. В результате у вас есть реальный аккаунт, который не может завершить онбординг, а повторные попытки регистрации могут упереться в «email уже занят».

Как это выглядит без транзакции

Распространённый шаблон, генерируемый ИИ: insert user, затем insert profile, затем insert subscription — каждый отдельным вызовом. Когда шаг 2 проваливается, шаг 1 уже закоммитился. Теперь нужны коды очистки (удалить пользователя) и решение, что делать, если и очистка провалится.

Тот же поток с транзакцией и явным откатом

С атомарными записями вы рассматриваете три вставки как одну единицу: либо все три успешны, либо ни одной нет.

BEGIN;

INSERT INTO users (email, password_hash)
VALUES (:email, :hash)
RETURNING id INTO :user_id;

INSERT INTO profiles (user_id, display_name)
VALUES (:user_id, :display_name);

INSERT INTO subscriptions (user_id, plan)
VALUES (:user_id, :plan);

COMMIT;
-- If any statement fails, ROLLBACK;

Два правила делают это надёжным:

• Отправлять пользователю «успех» только после успешного COMMIT.
• Если что‑то бросилось, поймать это, ROLLBACK и вернуть одно понятное сообщение об ошибке.

Посткоммитные действия, такие как приветственные письма, должны работать после коммита (или ставиться в очередь), чтобы вы не отправили письмо человеку за аккаунт, который на самом деле не сохранился.

Чтобы протестировать, вставьте намеренную ошибку посередине (например, некорректный display_name) и убедитесь, что в базе нет строк для этого email после провала запроса.

Следующие шаги: исправление ошибок транзакций в приложениях, созданных ИИ

Если вы унаследовали приложение, сгенерированное такими инструментами, как Lovable, Bolt, v0, Cursor или Replit, полузаписи обычно указывают на отсутствующие или неоконченные границы транзакций. На счастье, это часто выглядит нормально в тестах «по счастливому пути», но ломается при реальном трафике, таймаутах или одном неожиданном null.

Признаки, что код не использует транзакцию правильно (или использует частично):

• Один API‑вызов пишет в несколько таблиц, но каждая запись делается в отдельной функции со своими вызовами БД.
• Ошибки ловятся и логируются, но код продолжает и возвращает success.
• Фоновые задания, письма или платежи выполняются посреди базы данных записей.
• Повтор создаёт дубликаты, потому что нет идемпотентности.
• Видны сиротские строки (профиль без пользователя, заказ без позиций).

Когда вы просите аудит кода, спрашивайте не просто «используем ли мы транзакции?», а где они начинаются и заканчиваются и что происходит при ошибке. Хороший аудит должен отметить риски целостности данных (внешние ключи, ограничения, частичные записи), а также сопутствующие проблемы, часто идущие с кодом, сгенерированным ИИ: сломанные потоки аутентификации, утёкшие секреты и риски SQL‑инъекций.

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

Если вы активно видите полузаписи в кодовой базе, созданной ИИ, FixMyMess (fixmymess.ai) специализируется на диагностике кода, ремонте логики, укреплении безопасности, рефакторинге рискованных мест и подготовке приложения к деплою. Их бесплатный аудит кода — практичный способ найти точную конечную точку, где нарушается атомарность, и определить безопасное поведение отката.