Respuesta.

Bulk UPDATE es un procedimiento crítico al modificar un gran número de filas en tablas relacionadas. En la historia de SQL, una implementación típica es UPDATE con subconsulta o JOIN. Problema: cualquier operación masiva de actualización sin control del orden de ejecución bloquea muchas filas, genera una escalada de bloqueos y puede llevar a deadlocks al realizar múltiples actualizaciones.

Solución:

Siempre divida el UPDATE en pequeños lotes (por ejemplo, por clave primaria o rangos de fechas).
Utilice enfoques orientados a SET a través de JOIN, pero evite actualizaciones masivas sin restricciones.
Aplique filtros correctamente, indexe los campos según las condiciones WHERE y considere el orden de las operaciones para las tablas relacionadas.

Ejemplo de código (PostgreSQL):

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

O de forma masiva:

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);

Características clave:

Evitar actualizar "toda la tabla a la vez" — siempre en lotes.
Utilizar índices en el campo que se actualiza y en el campo de filtro.
Establecer criterios de selección claros, evitando actualizaciones masivas de filas innecesarias.

Preguntas capciosas.

¿Qué sucederá si se inicia simultáneamente un UPDATE en tablas similares sin separar rangos o filtros opuestos?

Probablemente se producirá un deadlock: los procesos bloquean las mismas filas, esperando el uno al otro. Para evitarlo, los lotes no deben superponerse o deben ejecutarse estrictamente de manera secuencial.

¿Hay alguna diferencia entre UPDATE mediante JOIN y subconsulta en caso de un cambio masivo de estado?

Si hay índices adecuados, la diferencia clave radica solo en la legibilidad y a veces en el rendimiento de un SGBD específico. JOIN suele ser más rápido, ya que permite al optimizador crear un mejor plan.

¿Cuándo es relevante usar TRUNCATE/DELETE en lugar de UPDATE?

Si la lógica empresarial lo permite — por ejemplo, se requiere eliminar físicamente registros archivados o vaciar una tabla, en lugar de simplemente cambiar un estado. Pero para la actualización masiva de estados — solo UPDATE.

Errores comunes y antipatrón

UPDATE masivo "sin filtro": bloqueos, rollback, deadlock.
Falta de índices — escaneo completo de tablas.
Ejecución paralela de UPDATE sin dividir el rango por claves.

Ejemplo de la vida real

Caso negativo

En una gran tienda en línea, se ejecutaron múltiples UPDATE para cambiar el estado de pedidos y clientes simultáneamente, sin dividir por intervalos. Resultado: bloqueos mutuos, varias veces se necesitó un rollback forzado y se perdieron datos no guardados.

Ventajas:

Todo en una sola consulta.

Desventajas:

Posibles deadlocks, pérdida de rendimiento, rollback de grandes volúmenes de datos incluso por un pequeño error.

Caso positivo

Grandes conjuntos se dividieron en lotes, se ejecutaron estrictamente de manera secuencial y solo se procesaron filas necesarias según el filtro.