CollapsingMergeTree：删除标记如何抵消旧记录

做的事：真实模拟一条状态记录的insert-cancel-insert

代码CREATE TABLE demo.ctest (k UInt64, v String, sign Int8) ENGINE=CollapsingMergeTree(sign) ORDER BY k; INSERT INTO demo.ctest VALUES (1, 'active', 1); -- 真实先插入原始状态 INSERT INTO demo.ctest VALUES (1, 'active', -1); -- 真实插入取消标记（撤销上一行） INSERT INTO demo.ctest VALUES (1, 'inactive', 1); -- 真实插入新状态

验证：merge之前，3行真实都在；OPTIMIZE FINAL之后，抵消的一对真实消失了

实测 · 本机执行输出

-- merge前
SELECT * FROM demo.ctest ORDER BY k, sign;
→ 1  active    -1
  1  inactive   1
  1  active     1     ← 真实3行都在，3个part

OPTIMIZE TABLE demo.ctest FINAL;
SELECT * FROM demo.ctest;
→ 1  inactive   1     ← 真实(active,+1)和(active,-1)这对互相抵消消失了
                       -- 只剩(inactive,+1)这一行，因为它没有配对的-1来抵消

CollapsingMergeTree真实的抵消规则很直白：在同一个排序键(ORDER BY k)下，如果存在一对除sign外其余列完全相同、且sign分别是+1和-1的行，merge时真实会把这一对一起丢弃；本文的(active,+1)和(active,-1)正好是这样一对，真实被丢弃了；而(inactive,+1)没有配对的(inactive,-1)来抵消，真实原样保留了下来，最终结果正确反映了"这条记录最新状态是inactive"。

意外发现：抵消不一定要等merge，同一个part内真实立刻生效

实测 · 本机执行输出（+1/-1落在同一次INSERT里）

INSERT INTO demo.ctest2 VALUES (1, 'a', 1), (1, 'a', -1);   -- 真实同一条INSERT语句携带这一对

SELECT * FROM demo.ctest2;
→ （空）   ← 真实0行，没有等任何merge就已经抵消了

SELECT count() FROM system.parts WHERE table='ctest2' AND active;
→ 0   ← 真实这个part写入时就直接是空的

这是一个容易被"CollapsingMergeTree的去重要等merge"这句话误导的细节：真实的机制是，MergeTreeDataWriter在把一批数据组织成一个part写入磁盘之前，会真实先在内存里对这一批数据本身做一次预处理层面的抵消（如果这一批数据里刚好包含能配对抵消的+1/-1行），所以本文这次"同一条INSERT语句携带一对+1/-1"的场景，真实在数据落盘之前就已经被处理掉了，连一个空的part文件之外什么都没剩下。这跟本文第一个实验（3行分别来自3次独立INSERT）形成对照：只要能抵消的一对不在同一次写入批次里，就必须真实等到后续的merge把它们放进同一个part一起处理时才会消失。这也是CollapsingMergeTree真实最容易踩的坑——如果应用层是"先发一条insert，过一会儿再发一条cancel"这种典型场景（本文的第一个实验），在两次写入之间的这段真实窗口期里，任何不做特殊处理的普通查询都可能同时读到新旧两条记录，需要业务方自己决定要不要用sign过滤、或者容忍这个窗口期内的短暂不一致。

分步演示：抵消发生的两种真实时机

每一步都是本文上面用真实CollapsingMergeTree跑出来的原始结果。

+1/-1成对抵消：merge时抵消，同批次立即抵消

这一步新验证的场景

本文用到的工具

本机 ClickHouse 26.9.4（单节点），真实的 CollapsingMergeTree(sign)
真实对比跨part抵消（需要merge）与同part抵消（写入时即生效）两种场景

下一篇 · CLICKHOUSE 内部原理 26

VersionedCollapsingMergeTree：乱序数据怎么折叠