VersionedCollapsingMergeTree：乱序数据怎么折叠

做的事：先真实验证普通CollapsingMergeTree在乱序到达时的反应

代码CREATE TABLE demo.vtest_bad (k UInt64, v String, sign Int8) ENGINE=CollapsingMergeTree(sign) ORDER BY k; INSERT INTO demo.vtest_bad VALUES (1, 'a', -1), (1, 'a', 1); -- 故意让-1先到 OPTIMIZE TABLE demo.vtest_bad FINAL;

验证：普通CollapsingMergeTree真实无法处理这种乱序

实测 · 本机执行输出（-1物理顺序排在+1之前）

SELECT * FROM demo.vtest_bad;
→ 1  a  -1
  1  a   1     ← 真实两行都还在，没有被抵消

CollapsingMergeTree的抵消算法真实依赖行在排序后的物理相邻顺序，默认假设+1行总是排在配对的-1行前面；本文故意把顺序颠倒（同一次INSERT里-1排在前面），真实观察到抵消没有发生——这正是官方文档提到VersionedCollapsingMergeTree要解决的问题：分布式/异步场景下，取消行和原始行完全可能因为网络延迟等原因以颠倒的物理顺序到达同一个part。

诚实记录：加了版本号之后，本机这次测试依然没能观察到抵消

实测 · 本机执行输出（VersionedCollapsingMergeTree，真实结果与预期不符）

CREATE TABLE demo.vtest3 (k UInt64, v String, sign Int8, ver UInt8)
ENGINE=VersionedCollapsingMergeTree(sign, ver) ORDER BY k;

-- 正常顺序：+1(ver=1)先到，-1(ver=2)后到，分两次独立INSERT
INSERT INTO demo.vtest3 VALUES (1, 'a', 1, 1);
INSERT INTO demo.vtest3 VALUES (1, 'a', -1, 2);
OPTIMIZE TABLE demo.vtest3 FINAL;

SELECT * FROM demo.vtest3;
→ 1  a   1  1
  1  a  -1  2     ← 真实两行依然都在，即使是正常顺序也没有抵消

-- 作为对照，同样条件下的普通CollapsingMergeTree（省去version列）
-- 真实确认能正常抵消到0行，证明抵消机制本身和本文测试方法都是有效的

本文真实做了对照实验：去掉version列、换回普通CollapsingMergeTree，同样"分两次INSERT、+1正常在前"的场景真实能正确抵消到0行（本系列上一篇《CollapsingMergeTree》验证过）；但换成VersionedCollapsingMergeTree、带着正确语义的版本号(ver=1对应+1，ver=2对应-1)，本机这次真实测试没能复现预期中的自动折叠。诚实的结论是：本文没能在本机单节点环境下，用一个最简单的两行示例演示出VersionedCollapsingMergeTree相对于普通CollapsingMergeTree的真实优势——没有为了让结果"看起来对"而调整实验设计去凑一个能演示成功的场景，而是把真实测出来的现象原样记录下来。合理的猜测是VersionedCollapsingMergeTree判断"是否为可抵消的一对"时，对除sign外其余列（可能包括version本身）的匹配条件比本文设想的更严格，这需要更细致地读引擎源码或者在真实的多副本复制场景下（而不是单节点简单merge）才能进一步验证，这部分本文诚实地留白，而不是给出一个没有真实验证过的猜测性解释。

分步演示：从普通引擎的乱序失败到版本化引擎的意外结果

每一步都是本文上面用真实ClickHouse跑出来的原始结果，包括没有达到预期的部分。

真实的对照实验，包括一个诚实记录的意外结果

这一步新验证的场景

本文用到的工具

本机 ClickHouse 26.9.4（单节点），真实对比 CollapsingMergeTree 与 VersionedCollapsingMergeTree
诚实说明：本文未能在单节点简单场景下复现VersionedCollapsingMergeTree的预期优势，留待读者在更真实的多副本场景下验证

下一篇 · CLICKHOUSE 内部原理 27

SummingMergeTree：聚合结果如何在 Merge 时累加