ReplacingMergeTree适合最终一致去重，依赖后台合并而非实时去重，需显式指定ORDER BY和可选version列；SummingMergeTree要求非聚合列必须为排序键前缀；AggregatingMergeTree必须配合AggregateFunction类型及State/Merge函数使用。
ReplacingMergeTree 适合去重但不保证实时性
当你需要按主键去重、且能接受“最终一致”时，ReplacingMergeTree 是最常用的选择。它靠后台合并（merge）阶段删除重复行，不是写入时即时去重。
常见错误现象：SELECT * FROM table 仍看到重复数据；OPTIMIZE TABLE 后才变干净；用 FINAL 查询又慢又锁表。
- 必须显式指定排序键（
ORDER BY），去重依据是该键 +version列（可选），版本大的保留 - 不设
version列时，最后写入的行胜出，但无法控制“最后”是哪一次 —— 合并顺序由 ClickHouse 内部调度决定 -
FINAL查询会强制触发合并，线上慎用；高并发写入下，ReplacingMergeTree的去重延迟可能达分钟级 - 如果业务要求“写入即可见最新”，别用它，改用物化视图 +
ReplacingMergeTree预聚合，或直接上VersionedCollapsingMergeTree
SummingMergeTree 要求严格分组聚合，不能混用非聚合列
SummingMergeTree 在 merge 时自动对指定列求和，但前提是：所有非聚合列必须是排序键的前缀，否则数据会“被截断”或聚合错乱。
使用场景：用户行为计数、订单金额累加等明确可加和的指标汇总。
- 定义引擎时用
SUMMINGMERGETREE(<code>sum_col1,sum_col2) 指定求和列；其余列必须全部包含在ORDER BY中，且顺序一致 - 如果漏掉某个非聚合列在
ORDER BY里，ClickHouse 不报错，但 merge 后该列值取“任意一行”，结果不可预测 - 它不处理 null 合并：两个
NULL求和仍是NULL，不是 0；需要提前用coalesce(col, 0)清洗 - 性能上比
MergeTree略低，因为每次 merge 都要计算求和；但比手动GROUP BY查询快得多
AggregatingMergeTree 必须配 Combine 类型字段，否则聚合失效
AggregatingMergeTree 不是自动聚合，而是依赖 AggregateFunction 类型字段存中间状态。写入不用聚合函数？那它跟普通 MergeTree 没区别。
错误典型：CREATE TABLE ... (metric SimpleAggregateFunction(sum, UInt64)) 写法已废弃，新版必须用 AggregateFunction(sum, UInt64) + State / Merge 函数配合。
- 写入必须用
xxxState()函数，例如sumState(clicks)；直接插原始值会导致后续xxxMerge()计算失败 - 查询必须用
xxxMerge()，例如sumMerge(metric)；漏掉就返回二进制 blob，不是数字 - 不支持在
WHERE中直接过滤AggregateFunction字段，得先Merge再过滤，或用物化视图预展开 - 磁盘占用比
SummingMergeTree高 2–3 倍，因存的是序列化状态；适合复杂指标（如 uniq、topK、quantile）
引擎选型卡点：排序键设计决定一切
三个引擎都强依赖 ORDER BY，但它不是“为了排序”，而是划分数据分片和合并粒度的依据。选错排序键，再好的引擎也白搭。
-
ReplacingMergeTree：把去重维度全放前面，比如ORDER BY (user_id, event_type, date)；加date可限制合并范围，避免跨月数据被误删 -
SummingMergeTree：非聚合列必须是排序键前缀，例如想按(user_id, date)汇总，就不能只写ORDER BY user_id -
AggregatingMergeTree：排序键需覆盖所有用于分组的维度，否则Merge时不同分组状态会被混在一起，结果发散 - ClickHouse 不支持多级排序键“优先级”，
ORDER BY (a, b)和ORDER BY (b, a)物理存储完全不同，改了就得重建表
真正难的不是选哪个引擎，而是想清楚：你的数据按什么维度分片、哪些字段必须对齐、下游查询是否允许延迟。这些没理清，换引擎只是把问题从运行时搬到 schema 设计阶段。
