Respuesta.

La eliminación masiva de decenas de millones de filas es una de las operaciones más típicas y peligrosas, especialmente en bases de datos de alto rendimiento. Históricamente, muchos simplemente escribieron DELETE FROM, lo que llevó a bloqueos de tabla y al desbordamiento del registro de transacciones. El problema principal: la transacción se vuelve demasiado grande, los procesos de servicio se ralentizan y las consecuencias de una reversión pueden ser difíciles de predecir.

Solución: implementar la eliminación "por lotes" (batch), procesando una pequeña cantidad de filas en un bucle con transacciones cortas, para minimizar bloqueos e impacto en el sistema:

Ejemplo de código (SQL Server):

WHILE 1=1
BEGIN
   DELETE TOP (10000)
   FROM YourHugeTable
   WHERE CreatedAt < DATEADD(year,-2,GETDATE());

   IF @@ROWCOUNT = 0 BREAK;
   WAITFOR DELAY '00:00:01'; -- pausa corta para disminuir la carga
END

Características clave:

Se minimiza el tamaño de los bloqueos y la escritura en el registro de transacciones.
El procesamiento se realiza en pequeñas porciones: el sistema permanece receptivo.
Se puede combinar con la visualización del progreso o la lógica de monitoreo externa.

Preguntas capciosas.

Si se hace un TRUNCATE en lugar de DELETE, ¿siempre será esto más rápido y seguro?

No. TRUNCATE es mucho más rápido, pero:

No se puede aplicar TRUNCATE si hay una clave externa que referencia la tabla.
TRUNCATE no activa los triggers.
TRUNCATE elimina completamente todas las filas, no bajo condición.

¿Es importante utilizar índices en el campo de filtro en una eliminación masiva?

Sí, tener un índice adecuado en la columna de filtro (por ejemplo, CreatedAt) acelera la búsqueda de filas a eliminar y reduce la carga en la tabla. Sin un índice, la consulta afectará toda la tabla, incluso si se eliminan pocas filas en cada porción.

CREATE INDEX idx_createdat ON YourHugeTable(CreatedAt);

¿Qué sucede si se ejecutan varios hilos de eliminación masiva al mismo tiempo?

Esto conducirá a la competencia por bloqueos: se producirán escaladas de bloqueos, aumento del tiempo de espera y una probabilidad de deadlock. La eliminación masiva de una tabla debe llevarse a cabo en un solo proceso, o con una división de rangos muy cuidadosamente pensada.

Errores típicos y antipatróns

Eliminación masiva en una sola transacción (bloquea la tabla, desborda el registro de transacciones).
Falta de verificación del progreso y control del tiempo de ejecución.
Ausencia de índices: se escanea toda la tabla cada vez.

Ejemplo de la vida real

Caso negativo

El DBA decidió limpiar una tabla de 60 millones de filas con una única consulta DELETE FROM Log WHERE dt < '2021-01-01'. El servidor casi "se cuelga", los demás procesos comenzaron a esperar la ejecución, el archivo de registro creció drásticamente y la recuperación se volvió larga.

Pros:

Fácil de implementar.

Contras:

Caída significativa del rendimiento de todo el servidor, posible pérdida de datos en caso de fallos, la recuperación tarda mucho.

Caso positivo

La eliminación se dividió en lotes de 10,000 filas, el proceso se controla, después de cada porción hay una pausa. El servidor funciona de manera estable, se realizan otras tareas, el administrador monitorea el progreso.