两三亿行的日分区里查交易明细，ClickHouse 依次按分区、part 的最值、稀疏主键和跳数索引跳过数据。明细换成 ReplacingMergeTree 后要带 FINAL 读，代价随重叠变；3 亿行时它只用一两百 MiB，精确去重要 18 GiB。

一批交易明细 INSERT 进复制表之后，服务端按分区切块、排序压缩成新的 part，后台 merge 把小 part 合大，另外两个副本照着 Keeper 里的复制日志去拉。part 写完不再改，去重、改数据和修数据的做法都从这一点来。

按 _part、_part_offset 删掉重复的那份，带子查询的 DELETE 在复制表上先被拒；放开之后子查询跟着全表 part 数重复执行。加上 IN PARTITION 它反而最省，但同一秒写进来的两份按 create_time 分不开。

同事准备用 mutation 修复 ClickHouse 表里写坏了 18 天的一列。评审方案时用只读连接把表的现状摸了一遍，意见主要提在回滚上。