ClickHouse集群删除后写入同日期数据如何避免新旧数据冲突？

问题根源 #

ClickHouse的ALTER ... DELETE属于Mutation操作，提交后仅会向集群节点下发删除任务，实际的物理数据清理是后台异步执行的。所以语句返回速度快，但查询时仍会看到未被物理删除的数据（已标记删除的行会被查询逻辑过滤，但磁盘文件未立即删除，导致行数缓慢减少），此时直接写入同日期数据确实可能出现新旧数据共存的情况。

解决方案 #

1. 等待Mutation完全完成后再写入

先确认全集群节点的删除任务执行完毕，再开始写入新数据：

• 查询system.mutations表跟踪任务状态：

  SELECT database, table, mutation_id, is_done, progress
  FROM system.mutations
  WHERE database = 'db' 
    AND table = 'tb' 
    AND command LIKE '%DELETE where event_date = 20231212%';
  

• 当所有返回结果的is_done字段变为1，且progress显示100%时，说明删除任务已在全集群完成，此时写入不会出现数据混合问题。
• 可以编写简单的Shell/Python脚本轮询该查询结果，自动等待任务完成。

2. 改用分区替换操作（推荐，适合按日期分区的表）

如果你的表是按event_date分区的，直接删除分区再写入新数据是同步且原子的操作，从根源避免异步清理的问题：

• 先删除目标分区（执行完成后分区立即被移除）：

  ALTER TABLE db.tb ON CLUSTER cl1 DROP PARTITION '20231212';
  

• 直接写入event_date=20231212的新数据，ClickHouse会自动创建对应的分区，整个过程无中间状态，不会出现新旧数据混合。
• 该方法比Mutation效率更高，因为是直接操作分区文件，没有后台异步清理的开销。

3. 临时用查询过滤规避混合（应急场景）

如果必须立即写入且无法等待Mutation完成，可以在写入新数据时增加一个版本标记字段（比如data_version），写入时设置为当前时间戳或唯一标识；后续查询event_date=20231212的数据时，只取最新版本的记录：

SELECT * FROM db.tb 
WHERE event_date = 20231212 
ORDER BY data_version DESC 
LIMIT 1 BY <主键字段>;

不过这种方法只是临时规避，优先推荐前两种方案从根源解决问题。

内容的提问来源于stack exchange，提问作者Alexandr