Ответ.

Bulk UPDATE — критичная процедура при изменении большого числа строк по связанным таблицам. В истории SQL типичная реализация — UPDATE с подзапросом или JOIN. Проблема: любая массовая операция обновления без контроля порядка выполнения блокирует множество строк, вызывает эскалацию блокировок и может привести к deadlock при множественных обновлениях.

Решение:

• Всегда разбивайте UPDATE на небольшие батчи (например, по primary key или диапазонам дат).
• Используйте SET-ориентированные подходы через JOIN, но избегайте массового обновления без ограничений.
• Грамотно накладывайте фильтры, индексируйте поля по условиям WHERE, учитывайте порядок операций для связанных таблиц.

Пример кода (PostgreSQL):

UPDATE Orders o
SET status = 'archived'
FROM Customers c
WHERE o.customer_id = c.id
  AND c.closed = TRUE
  AND o.status != 'archived';

Или пакетно:

WITH upd AS (
   SELECT o.id
   FROM Orders o
   JOIN Customers c ON o.customer_id = c.id
   WHERE c.closed = TRUE
   AND o.status != 'archived'
   LIMIT 10000
)
UPDATE Orders
SET status = 'archived'
WHERE id IN (SELECT id FROM upd);

Ключевые особенности:

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

Вопросы с подвохом.

Что произойдет, если одновременно запустить UPDATE схожих таблиц без разделения диапазонов или встречных фильтров?

Вероятно возникновение deadlock: процессы блокируют одни и те же строки, ожидая друг друга. Для избежания — пакеты должны не пересекаться или запускаться строго последовательно.

Есть ли разница между UPDATE через JOIN и подзапрос, если речь о массовой смене статуса?

Если есть подходящие индексы, ключевое отличие — только в читаемости и иногда в производительности конкретной СУБД. JOIN обычно быстрее, т. к. позволяет оптимизатору составить лучший план.

Когда актуально использовать TRUNCATE/DELETE вместо UPDATE?

Если бизнес-логика допускает — например, требуется физически удалить архивные записи или обнулить таблицу, а не просто поменять флаг статуса. Но для массового обновления статуса — только UPDATE.

Типовые ошибки и анти-паттерны

• Массовый UPDATE "без фильтра": блокировки, откат, deadlock.
• Отсутствие индексов — полное сканирование таблиц.
• Параллельный запуск UPDATE без деления диапазона по ключам.

Пример из жизни

Негативный кейс

В большом интернет-магазине запускали множественные UPDATE для смены статуса заказов и покупателей одновременно, без деления по intervу'lam. Итог: взаимные блокировки, несколько раз понадобился принудительный откат и откатились незаписанные данные.

Плюсы:

• Всё в одном запросе.

Минусы:

• Возможны deadlock, потеря производительности, откатываются огромные массивы данных даже при малой ошибке.

Позитивный кейс

Большие выборки бились на батчи, запускались строго последовательно, обрабатывались только необходимые строки по фильтру.

Плюсы:

• Стабильная работа базы.
• Производительность не страдает.

Минусы:

• Больший объём кода, требуется мониторинг за выполнением пачек.