Respuesta.

Historia de la pregunta:

La actualización masiva de datos es solicitada durante migraciones, transferencias, correcciones de lógica de negocio. Un ejemplo típico: es necesario cambiar el estado de decenas de millones de filas en una tabla activa, sin detener el servicio, manteniendo la disponibilidad y el rendimiento.

Problema:

Un UPDATE normal sin restricciones se ejecuta lentamente, puede llevar a la escalada de bloqueos, bloquea la tabla y resulta en un rollback colectivo en caso de error. Se requiere un enfoque que minimice el impacto en los usuarios y garantice la transaccionalidad.

Solución:

Dividir la operación en lotes utilizando WHERE y LIMIT/TOP.
Utilizar funciones de ventana, tablas temporales, puntos temporales.
A veces, quitar temporalmente los índices, fijar puntos de guardado (SAVEPOINT), usar un nivel de aislamiento más bajo.

Ejemplo de código:

-- Ejemplo de actualización por lotes de 10,000 filas
WHILE 1 = 1
BEGIN
  UPDATE TOP (10000) mytable
  SET status = 'archived', updated = GETDATE()
  WHERE status = 'active';
  IF @@ROWCOUNT = 0 BREAK;
END

Características clave:

El procesamiento por lotes reduce la duración del mantenimiento de bloqueos
La atomicidad se garantiza solo dentro de cada mini-transacción
Algunas bases de datos tienen operadores bulk especiales que aceleran el trabajo con grandes volúmenes

Preguntas capciosas.

¿Se puede hacer una actualización masiva en una transacción y no bloquear la tabla?

Por lo general, no. Una gran transacción bloquea la tabla/páginas y aumenta el riesgo de bloqueos y timeouts. Es mejor trabajar en lotes.

¿Influye la presencia de índices en la velocidad de la actualización masiva?

Sí. Cualquier actualización de campos indexados requiere reestructuración del índice para cada fila. A veces es conveniente quitar índices temporalmente, pero esto requiere un análisis profundo.

¿Todas las filas se actualizan de manera atómica en las actualizaciones por lotes?

No, la atomicidad se garantiza solo dentro de un lote (límite de filas/transacción). Si se interrumpe un lote, algunas filas se actualizarán y otras no. Para una verdadera atomicidad, se necesita solo una actualización completa en una transacción, lo que es arriesgado con grandes volúmenes.

Errores comunes y anti-patrones

Actualización instantánea sin límite, que provoca escalada de bloqueos
No tener en cuenta los índices — esperar un alto rendimiento en columnas indexadas
No usar puntos de guardado (SAVEPOINT)

Ejemplo de la vida real

Caso negativo

Un ingeniero técnico decidió actualizar 10 millones de filas con una sola consulta en una base de datos productiva: UPDATE mytable SET status = 'archived'. El sitio "se congeló", el rollback tomó decenas de minutos, afectando el rendimiento.

Pros:

Simplicidad del comando, mínimo código Contras:
Congelamiento/bloqueo del servicio de producción
Posible gran rollback de la transacción en caso de error

Caso positivo

La consulta se dividió en lotes de 10,000 filas con transacciones cortas, la actualización se realiza en horas laborales sin tiempo de inactividad.