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

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

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

用 argMin 重建出事窗口再 REPLACE 的清理方案，在三副本 lab 里先报语法错；修好之后，列序错位、迟到写入、落后副本、只看一个节点的核对，以及换分区落到临时表还没复制到的副本，都能让数据坏掉或丢掉，行数校验照样通过。

Kafka 到 ClickHouse 的链路上，重复行能从 producer 重试、sink 超时重投、task 重启重放和人工补发四处进来。lab 实测 sink 的 exactlyOnce 挡得住重放，挡不住超时重投，打开后崩溃重启默认停在状态冲突上。

ClickHouse 没有 UPSERT，清掉已写进去的重复行，要从快照把一整天重建好、验过，再用 REPLACE PARTITION 整个换进去。R0 到 R8 的几道闸挡住副本落后、快照之后的写入和换分区落到没复制完的副本，回滚是反向再换一次。

ReplicatedMergeTree 默认记住最近 1000 个插入块，重投的那批内容和 token 都没变，本该被认出来。这张表三个副本每秒建 124 个块，1000 个块折合 8 秒，而重投的间隔是 32 到 124 秒。

同一个业务键在 ClickHouse 里出现两行完全一样的数据，写入时间相差 30 秒到两分钟。前一天吞吐掉到常态零头的十几个小时一行重复都没有，出重复的是第二天吞吐看着正常、Keeper 在途请求涨到几千的那三个小时。

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