ClickHouse SummingMergeTree 详解：后台合并机制、最佳实践与避坑指南

ClickHouse 的 MergeTree 家族我用了不少年头，越用越觉得这个“家族”设计得很妙：MergeTree 本身只是一个带排序、带分区、支持后台合并的存储底座，真正让它在海量数据下还能压住成本、保住查询性能的，是长在这个底座上一大票各怀绝技的表引擎。今天要聊的 SummingMergeTree，是家族里性价比很高、但也很容易被用偏的一个。它能在后台合并时把相同排序键的多行数据累加成一行，显著压缩存量、减少查询扫描量；但你一旦按普通 MergeTree 的思路去看它，很快会被一些反直觉的行为坑到。

这篇文章会从它诞生的原因讲起，拆解后台合并的完整机制，然后带你把建表、写入、触发合并、查询的整条链路跑通，最后再给出一份家族横向对比和实战问题清单。无论你是刚接触 ClickHouse、正在为报表类任务选表引擎，还是已经上生产但被重复行、合并时机、字段顺序问题折磨过，这篇都值得你从头到尾读一遍。

1. 从 MergeTree 到 SummingMergeTree：这条链路到底解决了什么问题

1.1 MergeTree 的痛点与 SummingMergeTree 的定位

先回到源头。普通 MergeTree 能干的事其实是：按照 ORDER BY 指定的列排序存储、按 PARTITION BY 分区、按主键建稀疏索引。它的写入是按“数据部分（data part）”的方式落盘的，每个 INSERT 都会生成新 part，后台再把小 part 合并成大 part。

这个模型有一个天然问题：如果业务反复写入带有“汇总性质”的数据，比如每隔几分钟上报一次页面浏览量、每次读取计数器快照、每笔订单状态变更都插入一行，那么同一把业务键（设备 ID、商品 ID、订单 ID）在表里会有成百上千行。时间一长，part 里堆满了重复键，查询时即使有索引，也要扫出大量明细行再做 GROUP BY，磁盘占用和查询耗时都会被放大。

SummingMergeTree 的定位非常明确：在后台合并 part 的过程中，顺手把 ORDER BY 键相同、且可以进行数值累加的列做一次预聚合，把多行变成一行。这样数据量会在不知不觉中被压缩下来，查询时扫描的行数变少，很多报表 SQL 的 GROUP BY 压力也会小一个量级。它不保证任何时刻数据都是聚合好的，但保证“合并完成之后、以 FINAL 方式查询或自己再用 SUM 聚合，都能拿到正确结果”。

1.2 什么样的业务适合用它

我自己的判断标准就三条：有明确的维度键、有可累加的数值指标、能接受“异步聚合”的最终一致性。

典型场景是统计类流水。比如每个页面的 PV/UV（UV 可以单独处理）、每个商品的曝光数和点击数、每台服务器的 CPU 使用率累计、每张订单的实付金额变更流水。这些数据天然是“原始明细 + 周期内多行”的结构，用 SummingMergeTree 按维度键去重累加，效果立竿见影。

不太适合的场景也很明确：如果你需要实时精确的预聚合结果，比如“刚写完就必须立刻查到只加了一行”，那它不合适。SummingMergeTree 的合并是异步的后台行为，INSERT 完成后数据仍然以多行形式存在，只有等合并发生才会真正折叠。所以它更适合对分钟级延迟不敏感、最终能用 SQL 聚合纠正结果的场景。

顺带回应一个很常见的疑问：老有人拿 ClickHouse 和 Spark 比，说 Spark 也能做聚合。其实这俩不在一个赛道。ClickHouse 是 OLAP 数据库，负责存储和查询；Spark 是分布式计算框架，负责大规模计算。SummingMergeTree 的特殊之处，是把“预聚合”下沉到了存储引擎的合并流程里，属于数据库层面的能力。你可以把它的定位理解成数据库内部的轻量级物化机制，而不是完整的数据处理框架。

2. SummingMergeTree 的核心合并机制，一次讲透

2.1 “后台合并”而不是“写入时聚合”

很多人第一次用这个引擎都会有个误区：以为 INSERT 进去的时候，相同键的数据就直接被加到一起。真相完全不是这样。

每次 INSERT 都会生成一个独立的 part，部分数据保持原始多行形态。真正的合并发生在后台线程里，ClickHouse 会按分区挑选若干 part，把它们的行按 ORDER BY 排序、归并，然后把排序键相同的行合并成一行。这个合并任务受很多因素影响：part 的大小、数量、服务器的合并线程压力、merge_tree 配置里的 parts_to_throw_insert 等参数。所以“合并后到底剩几行”在任意时刻都无法精确预知，你只能保证最终会收敛。

可以做一个简单实验验证。建一张 SummingMergeTree 表，往里面分三次插入相同键的数据，每次插入之间不做任何操作，然后直接 SELECT，你会看到三行还在；再不指定任何参数执行 OPTIMIZE TABLE xxx FINAL，再看，变成一行了。这个行为理解透了，后面很多问题都不会再卡住你。

合并的粒度是按分区来的，不同分区的数据永远不可能被后台任务合到一起。所以如果你的分区键是 toYYYYMM(date)，同一把业务键出现在不同月份时，会保留为多行。这在时间序列场景下是合理的，因为查询基本都带时间过滤条件；但如果你的业务键本身跨分区且希望全局唯一，需要在设计 ORDER BY 和 PARTITION BY 时想清楚。

2.2 到底哪些列会被求和，哪些不会

这里是最容易踩坑的地方，我把规则整理成一句话：

• ORDER BY 中出现的列，是“分组键”，不参与求和。
• 除了分组键之外，数值类型（整数、浮点数、Decimal 等）的普通列，默认全部参与求和。
• 非数值类型、或者没有出现在求和列表中的数值列，合并时取第一行的值，而且是“不确定的第一行”。

这个“不确定”不是开玩笑。因为合并时相同键的行来自多个 part，它们在 part 内的顺序、part 被选中合并的顺序都会影响谁排在前面。你要是把一个商品名称、一个状态描述之类的列放在非键位置又希望保留某个确定的值，合并完很可能得到随机结果。所以正确的做法是：把需要保留的维度字段全部写进 ORDER BY，或者在引擎参数里显式指定哪些列参与求和。

你可以在建表时给 SummingMergeTree 传一个列名列表，格式是 SummingMergeTree(col1, col2)。这个设计非常实用，尤其是同一行里既有“需要累加的指标”，又有“绝对不能累加的数值属性”时。比如说电商订单流：订单金额 amount 需要累加，商品单价 price 是属性值，单价相加没有任何业务意义。这种情况就要显式写成 SummingMergeTree(amount)，否则合并出来的金额会离谱到没法看。

2.3 Nested 结构 + Map 后缀的特殊玩法

当某个指标本身又是一张“小表”时，SummingMergeTree 也有对应的处理方式。你可以在表里建一个 Nested 类型的列，当这个 Nested 列名以 Map 结尾，并且内部包含 key 和 value 两个子列时，合并逻辑就会变得很聪明：它不再简单地把整个 Nested 数组的所有元素求和，而是按 key 分组，把同一个 key 的 value 累加。

举个例子。假设你统计每个商品的按渠道访问量，渠道集合是不固定的，这时候用普通列设计会很痛苦。用 Nested + Map 后缀，建表大致长这样：

sql复制CREATE TABLE product_traffic
(
    product_id UInt64,
    date Date,
    trafficMap Nested
    (
        channel String,
        cnt UInt32
    )
)
ENGINE = SummingMergeTree
ORDER BY (product_id, date)

写数据时，每一次上报都携带一批渠道和对应数量。后台合并时，ClickHouse 会把不同行里相同 channel 的 cnt 加总，最终每个商品、每天只保留一行，行内是渠道维度去重后的 Map。这个能力做多维计数器非常方便，省得你在应用层自己维护复杂的去重结构。

不过要提醒一点：Map 后缀的 Nested 列在查询时依然要按 Nested 的语法展开，比如 arrayJoin(trafficMap.channel) 配合 trafficMap.cnt 使用，理解成本并不低。如果渠道集合是固定的，直接用普通列反而更简单。这种特殊玩法适合渠道维度多且动态增长的场景。

3. 实操全流程：建表、写入、触发合并与查询

3.1 建表语句与引擎参数怎么写

先看一个最常见的页面访问统计场景。我们要统计每个网站、每个页面、每天的浏览量，原始数据里一个页面可能有多条上报记录。建表语句如下：

sql复制CREATE TABLE page_views
(
    site_id   UInt32,
    page_url  String,
    view_date Date,
    views     UInt32,
    duration  UInt64
)
ENGINE = SummingMergeTree
PARTITION BY toYYYYMM(view_date)
ORDER BY (site_id, page_url, view_date)

注意几个点。PARTITION BY 按月份分区，方便后续按时间做数据生命周期管理；ORDER BY 是 (site_id, page_url, view_date)，这三个字段就是合并时的分组键，也就是说合并后每个网站、每个页面、每天只会保留一行。views 和 duration 是两个数值列，默认都会被求和。

如果你希望展示型字段也保留在合并结果里，比如页面的标题 page_title，就把它加进 ORDER BY：

sql复制ORDER BY (site_id, page_url, page_title, view_date)

这样排序键变长了，索引文件和存储占用会略有上升，但换来的是合并后确定保留页面标题。取舍要在意业务正确性，而不是一味追求最小的排序键。

如果你要限制求和范围，用带参数的写法：

sql复制ENGINE = SummingMergeTree(duration)

此时只有 duration 参与求和，views 会合并成“第一行的值”。这种情况适用于你想手动控制聚合列的场景，比如 views 在同一批数据里本身已经去重过，不需要二次累加。

3.2 数据写入与合并行为验证

建好表后分三次插入相同键的数据模拟真实场景：

sql复制INSERT INTO page_views VALUES
(1, '/index.html', '2024-05-01', 10, 120);

INSERT INTO page_views VALUES
(1, '/index.html', '2024-05-01', 5, 60);

INSERT INTO page_views VALUES
(1, '/index.html', '2024-05-01', 8, 90);

不触发强制合并，先直接 SELECT：

sql复制SELECT site_id, page_url, view_date, views, duration
FROM page_views;

你大概率会看到三行原始数据。这说明 SummingMergeTree 并没有在写入时做任何聚合。接着执行：

sql复制OPTIMIZE TABLE page_views FINAL;

再查一次，三行变成了：

sql复制1   '/index.html'   '2024-05-01'   23   270

views 累加了，duration 也累加了。这就是 SummingMergeTree 最核心的“合并折叠”效果。

生产环境不会让你天天手动 OPTIMIZE，后台会自动合并。你可以用下面的 SQL 观察表内部的 part 变化：

sql复制SELECT table, partition, active, parts, rows, bytes_on_disk
FROM system.parts
WHERE table = 'page_views'
ORDER BY partition;

parts 字段代表当前活跃 part 数，rows 是这些 part 里的总行数。随着后台合并推进，你会看到 parts 减少、rows 下降。如果长时间不合并，优先检查是否积压了大量小 part，或合并线程配置是否被调得过保守。

3.3 查询的正确姿势：别把预聚合当终点

这是整个引擎使用中最核心的一条经验：SummingMergeTree 的预聚合不能替代 SQL 里的 SUM，查询时该写 GROUP BY 还是要写。

后台合并是异步的，任何时刻都可能有未合并的行；而且如果你查询范围跨多个分区，即使每个分区内部都合并好了，同一把键依然会出现在多行里。所以在报表 SQL 里，标准姿势是这样的：

sql复制SELECT
    site_id,
    page_url,
    view_date,
    sum(views)   AS total_views,
    sum(duration) AS total_duration
FROM page_views
WHERE view_date >= '2024-05-01'
GROUP BY site_id, page_url, view_date;

这里 GROUP BY 的字段和 ORDER BY 的键保持一致，sum(views) 只管兜底。已经合并的行，sum 一个数等于它本身；还没合并的行，sum 会把它们加到一起。两层机制叠加，结果才总是正确。

还有一个办法是查询时加 FINAL 关键字：

sql复制SELECT site_id, page_url, view_date, views, duration
FROM page_views FINAL;

FINAL 会在查询过程中对扫描到的数据实时应用一次合并逻辑，相当于把“后台待办”提前到查询时完成。它省事，但会显著增加查询开销，尤其是大数据量时，性能大概率不如自己写 GROUP BY。我的建议是：FINAL 用于验证、排查和小范围精确查询还行，生产报表一律用 GROUP BY + SUM。

4. 家族横向对比：SummingMergeTree vs ReplacingMergeTree vs AggregatingMergeTree

4.1 三个引擎的分工逻辑

ClickHouse 的 MergeTree 家族里，有三个引擎长得像、用途完全不同，常被放在一起比较。我把它们的分工概括成一句：SummingMergeTree 管“累加”，ReplacingMergeTree 管“去重”，AggregatingMergeTree 管“更复杂的聚合”。

ReplacingMergeTree 处理的是同一把键多行数据保留最新一行的问题，通常配合 VER 版本列或时间戳使用。它的典型场景是缓慢变化维度、状态快照，比如订单状态、用户最新资料。它解决的是“我只要最新记录”，而不是“我要把数值加起来”。

AggregatingMergeTree 则更进一步，它不限定聚合函数。你可以在物化视图或 INSERT SELECT 时指定 sumState、uniqState、avgState 等聚合状态函数，ClickHouse 会把聚合的中间状态存下来，后台合并时把相同键的状态合并。查询时再用 sumMerge、uniqMerge 把状态还原成结果。它能做精确去重计数（uniq）、求平均、求最大最小值，但使用门槛高很多，需要你理解“聚合状态”的概念。

SummingMergeTree 是三者里最“轻”的：它不需要额外的状态表示，列本身存的就是可累加的数值，合并逻辑简单粗暴，查询时也不需要任何特殊的 Merge 函数，普通 SUM 就能正确。因为这一层简单，它的性能损耗和运维成本是最低的。

4.2 选型与组合使用的实际经验

我的选型经验可以浓缩成三句话：

• 指标只涉及求和，选 SummingMergeTree。
• 需要最新状态，选 ReplacingMergeTree。
• 需要去重计数、平均数等复杂聚合，选 AggregatingMergeTree。

在实际项目里这三个引擎经常是配合使用的。比如一张订单明细表用 ReplacingMergeTree 保证每个订单只保留最新状态；同时做一个物化视图，把订单金额写到一张 SummingMergeTree 的统计表里，实现按天、按维度的自动累加。物化视图 + SummingMergeTree 的组合，是我觉得 ClickHouse 在报表场景性价比最高的架构之一。

有一个非常常见的坑是：一张表既要“最新值”又要“累计值”，结果有人用 SummingMergeTree 硬扛，把非数值字段写进 ORDER BY，导致排序键膨胀、合并效率变差。遇到这种混合需求，最好的做法是拆表。最新状态归 ReplacingMergeTree，累计指标归 SummingMergeTree，让每个引擎只做自己擅长的事。

4.3 集群部署中容易踩的认证坑与备份要点

如果你把 SummingMergeTree 表放到分布式集群里，通常还会建 Distributed 引擎的分布式表做统一入口。集群模式下最典型的一个报错，就是热搜里那个 user: default: authentication failed: code: 193。不同版本错误码会有差异，新版本常见 516，但看到 “authentication failed” 这段时，别纠结错误码，重点排查以下几点。

第一是 users.xml 在节点间不一致。分布式表在转发查询到远端分片时，会用 <remote_servers> 里配置的用户名和密码去连接目标节点的本地用户。如果 default 用户在节点 A 有密码、在节点 B 是空密码，或者两边密码哈希不一致，查询转发就会认证失败。解决办法是把所有节点的 users.xml 中对应用户的密码配置对齐。

第二是配置了 <user> 和 <password> 但目标节点上根本没这个用户。这种情况常出现在用 SQL 方式创建用户、但 access_management 的权限变更没有正确同步到所有节点的场景。排查看远端节点本地是否真的存在这个用户：SELECT name FROM system.users。

第三是写了集群配置但没重启，或者分布式表指向的集群名拼写错误。先确认 <remote_servers> 里集群名和建 Distributed 表时用的名字完全一致，再看配置有没有真正加载到 system.clusters。

再补充一个备份的注意点。SummingMergeTree 本质上还是 MergeTree，备份方式和普通表没有区别，常见方案是 clickhouse-backup、BACKUP TABLE ... TO Disk(...) 命令，或者 ALTER TABLE ... FREEZE 做文件级快照。但有个容易忽略的细节：从旧备份恢复后，表里的 part 状态停留在备份时刻，后台合并还没跑完，所以相同键的行可能比线上多、预聚合程度低。这不会导致错误，因为查询兜底的 SUM 还在，只是你需要接受合并前临时性的数据膨胀，查询性能会略差。恢复后可以手动执行一次 OPTIMIZE TABLE ... FINAL 加速收敛。

5. 常见问题与排查技巧实录

5.1 为什么查询结果里还是有多行

这是被问得最多的一个问题。现象是明明建了 SummingMergeTree，查出来的数据还是有重复键。

原因前面已经提到过：合并是异步的，写入后立即查询、或者数据跨多个分区、或者后台合并还没轮到这批 part，都会看到多行。排查步骤我一般是这样：

先看 system.parts 确认 part 数量和行数，如果 part 很多但没在合并，检查合并线程配置或最近是否有大批量写入导致合并积压。再看查询条件是否跨分区。如果你按天分区却查询整月数据，同键多行跨分区是正常现象。最后，确认你没有把“求和键”设计错——ORDER BY 之外的数值列都求和，但 ORDER BY 里如果漏掉了某个维度，那个维度的键就成了同一把，合并会把它错误地折叠。

一切正常的话，你的报表 SQL 里只要保留了 GROUP BY + SUM，结果就是对的。对 SummingMergeTree 来说，“表里永远有多行”是常态，不是故障。

5.2 不想求和的数值列被“吞”了

另一个高频问题是：表里有个单价字段，结果合并后单价变成了某个不知名的数，怀疑数据丢失。

不是丢失，是它按“取第一行”的逻辑被保留了。这个第一行又是不确定的，所以看起来像随机数据。解决方式有两个：把单价这类属性列放进 ORDER BY，让它成为分组键的一部分；或者在建表时用参数明确指定只求和的列。两种方案我都试过，如果属性列基数不高，放进 ORDER BY 更直观；如果属性列取值很多、放进排序键会明显膨胀索引，就用参数列表指定求和列。

5.3 浮点求和结果和预期对不上

浮点列参与 SummingMergeTree 合并时，可能出现一个很有意思的问题：后台每轮合并的 part 组合顺序不同，浮点数累加的顺序就不同，而浮点加法不满足结合律，最终结果在小数位上会有细微差异。数据量越小越不明显，数据量大、part 多的时候可能会差那么零点几。

这不是引擎坏了，是浮点精度问题。生产环境凡是做金额、做对精度敏感的指标，都建议用 Decimal 类型而不是 Float。Decimal 是定点数，累加顺序不影响结果。如果历史表已经用了 Float，尽早迁移或者在应用层用高精度类型做最终换算。

5.4 最后几条实战避坑建议

写到这里，顺手整理几条我在项目中反复踩过、后来形成肌肉记忆的规则。

分区键和排序键要一起设计。分区键决定合并的边界，排序键决定合并的分组，两个维度的粒度要匹配业务。比如按天分区、按商品分组，同一个商品跨天就是多行，报表里必须紧跟日期条件。

大批量写入后不要马上依赖自动合并。数据导入任务做完后，如果业务要求尽快收敛，可以触发一次 OPTIMIZE TABLE ... FINAL。但注意，大数据量下这很吃资源，建议在业务低峰期执行，并且分批处理，不要一次 OPTIMIZE 整个大表。

监控 part 数量和合并延迟。我习惯给每个 SummingMergeTree 表加一张监控脚本，定时查 system.parts，如果活跃 part 数量持续上涨，说明合并跟不上写入速度。这时候优先考虑优化写入频率、减小单次 INSERT 体积，或者调整后台合并线程数量。等合并积压变成常态，查询性能和稳定性都会快速恶化。

最后再分享一个我个人的习惯：凡是建 SummingMergeTree 表，我永远在查询层保留 GROUP BY + SUM，不依赖表的“已合并”状态。哪怕某张表数据量很小、合并几乎实时完成，我也这么写。这样无论后台合并出了什么意外、恢复了什么备份、或者换了新版本改了合并策略，我的报表结果都不会错。这个习惯帮我省掉的排查时间，远比多写一个 GROUP BY 带来的开销要多。