Saltar al contenido principal
La sentencia DELETE de eliminación ligera elimina las filas de la tabla [db.]table que coinciden con la expresión expr. Solo está disponible para la familia de motores de tabla *MergeTree.
DELETE FROM [db.]table [ON CLUSTER cluster] [IN PARTITION partition_expr] WHERE expr;
Se denomina “DELETE ligero” para diferenciarlo del comando ALTER TABLE … DELETE, que es un proceso costoso.

Ejemplos

-- Elimina todas las filas de la tabla `hits` donde la columna `Title` contiene el texto `hello`
DELETE FROM hits WHERE Title LIKE '%hello%';

eliminación ligera no elimina los datos de inmediato

eliminación ligera se implementa como una mutación que marca las filas como eliminadas, pero no las elimina físicamente de inmediato. De forma predeterminada, las Sentencias DELETE esperan a que se complete el marcado de las filas como eliminadas antes de finalizar. Esto puede llevar mucho tiempo si el volumen de datos es grande. Como alternativa, puede ejecutarlo de forma asíncrona en segundo plano mediante la configuración lightweight_deletes_sync. Si está deshabilitada, la sentencia DELETE devolverá el resultado de inmediato, pero los datos pueden seguir siendo visibles para las consultas hasta que finalice la mutación en segundo plano. La mutación no elimina físicamente las filas que se han marcado como eliminadas; esto solo ocurrirá durante la siguiente fusión. Como resultado, es posible que, durante un período no especificado, los datos no se eliminen realmente del almacenamiento y solo queden marcados como eliminados. Si necesita garantizar que sus datos se eliminen del almacenamiento en un tiempo predecible, considere usar la configuración de tabla min_age_to_force_merge_seconds. O bien, puede usar el comando ALTER TABLE … DELETE. Tenga en cuenta que eliminar datos con ALTER TABLE ... DELETE puede consumir una cantidad significativa de recursos, ya que vuelve a crear todas las partes afectadas.

Eliminación de grandes volúmenes de datos

Las eliminaciones de gran volumen pueden afectar negativamente el rendimiento de ClickHouse. Si intenta eliminar todas las filas de una tabla, considere usar el comando TRUNCATE TABLE. Si prevé eliminaciones frecuentes, considere usar una clave de particionamiento personalizada. Después, puede usar el comando ALTER TABLE ... DROP PARTITION para eliminar rápidamente todas las filas asociadas a esa partición.

Limitaciones de la eliminación ligera

Eliminaciones ligeras con proyecciones

De forma predeterminada, DELETE no funciona en tablas con proyecciones. Esto se debe a que las filas de una proyección pueden verse afectadas por una operación DELETE. Sin embargo, existe la configuración de MergeTree lightweight_mutation_projection_mode para cambiar este comportamiento.

Consideraciones de rendimiento al usar eliminación ligera

Eliminar grandes volúmenes de datos con la instrucción de eliminación ligera puede afectar negativamente el rendimiento de las consultas SELECT. Los siguientes factores también pueden afectar negativamente el rendimiento de la eliminación ligera:
  • Una condición WHERE compleja en una consulta DELETE.
  • Si la cola de mutaciones está llena de muchas otras mutaciones, esto puede provocar problemas de rendimiento, ya que todas las mutaciones de una tabla se ejecutan de forma secuencial.
  • La tabla afectada tiene una cantidad muy grande de partes de datos.
  • Tener muchos datos en partes compactas. En una parte Compact, todas las columnas se almacenan en un único archivo.

Permisos de DELETE

DELETE requiere el privilegio ALTER DELETE. Para habilitar las Sentencias DELETE en una tabla específica para un usuario determinado, ejecute el siguiente comando:
GRANT ALTER DELETE ON db.table to username;

Cómo funcionan internamente las eliminaciones ligeras en ClickHouse

  1. Se aplica una “máscara” a las filas afectadas Cuando se ejecuta una consulta DELETE FROM table ..., ClickHouse guarda una máscara en la que cada fila queda marcada como “existente” o “eliminada”. Esas filas “eliminadas” se omiten en las consultas posteriores. Sin embargo, las filas en realidad solo se eliminan más adelante, durante fusiones posteriores. Escribir esta máscara es mucho más ligero que lo que se hace con una consulta ALTER TABLE ... DELETE. La máscara se implementa como una columna de sistema oculta, _row_exists, que almacena True para todas las filas visibles y False para las eliminadas. Esta columna solo está presente en una parte si se eliminaron algunas filas de esa parte. No existe cuando una parte tiene todos sus valores iguales a True.
  2. Las consultas SELECT se transforman para incluir la máscara Cuando se usa una columna enmascarada en una consulta, la consulta SELECT ... FROM table WHERE condition se amplía internamente con el predicado sobre _row_exists y se transforma en:
    SELECT ... FROM table PREWHERE _row_exists WHERE condition
    
    En tiempo de ejecución, la columna _row_exists se lee para determinar qué filas no deben devolverse. Si hay muchas filas eliminadas, ClickHouse puede determinar qué gránulos pueden omitirse por completo al leer el resto de las columnas.
  3. Las consultas DELETE se transforman en consultas ALTER TABLE ... UPDATE DELETE FROM table WHERE condition se traduce en una mutación ALTER TABLE table UPDATE _row_exists = 0 WHERE condition. Internamente, esta mutación se ejecuta en dos pasos:
    1. Se ejecuta un comando SELECT count() FROM table WHERE condition para cada parte individual, a fin de determinar si esa parte está afectada.
    2. A partir de los comandos anteriores, se aplican mutaciones a las partes afectadas y se crean enlaces físicos para las partes no afectadas. En el caso de las partes wide, se actualiza la columna _row_exists de cada fila, y los archivos de todas las demás columnas se enlazan mediante enlaces físicos. En el caso de las partes compact, todas las columnas se reescriben porque se almacenan juntas en un solo archivo.
    A partir de los pasos anteriores, podemos ver que el uso de eliminación ligera con la técnica de enmascaramiento mejora el rendimiento frente al ALTER TABLE ... DELETE tradicional porque no reescribe todos los archivos de columnas de las partes afectadas.
Última modificación el 10 de junio de 2026