SummingMergeTree 在聚合指标中的秒级响应放弃明细全表扫描的终极方案在设计高吞吐、高并发的企业级财务对账、流量统计和广告结算看板时最耗费计算资源的度量永远是基础数值的求和SUM(amount)、SUM(clicks)、SUM(views)。很多团队在把数据接入 ClickHouse 时习惯性地把所有事件明细全塞进标准的MergeTree引擎里。当单表记录数达到 50 亿行、历史跨度长达 2 年时业务端只要在页面上拉一个“按商户查看近 1 年月度总流水”的报表ClickHouse 哪怕利用多核并发全速扫描也需要从磁盘读取数十 GB 的压缩数据单次查询耗时在 3~8 秒左右。一旦周一早高峰几十个运营同时打开大屏数据库 CPU 直接被打到 100%。对于这种只关心数值累加、无需回溯单笔明细的业务场景ClickHouse 提供了原生的预聚合引擎——SummingMergeTree。它能够在后台异步合并数据片段Part时自动将具有相同排序键ORDER BY的数值列进行代数求和压缩将物理存储和扫描行数直接降低两个数量级。SummingMergeTree 的工作原理物理行自动折叠在标准MergeTree中每插入一条包含相同主键的流水磁盘上就会新增一行而在SummingMergeTree中后台合并线程Merge会自动将相同排序键的行进行合并把指定的数值列累加从而实现物理行数的“自动折叠”。[ 批次 1 写入 ] [ 批次 2 写入 ] (2026-09-03, 门店A, 商品X, 销售额: 100, 订单数: 2) (2026-09-03, 门店A, 商品X, 销售额: 50, 订单数: 1) \ / ▼ ▼ [ 后台触发 SummingMergeTree Compaction 归并折叠 ] ↓ (2026-09-03, 门店A, 商品X, 销售额: 150, 订单数: 3) -- 物理压缩为 1 行建表实战财务汇总表的设计与列定义创建SummingMergeTree时可以显式在括号内声明需要累加的列列表。如果省略括号ClickHouse 会默认将所有非主键的数值类型UInt*,Int*,Float*,Decimal*字段全部作为累加列CREATE TABLE dws_merchant_daily_financial_summary ( stat_date Date, merchant_id UInt32, channel_code LowCardinality(String), currency LowCardinality(String), -- 声明需要自动累加求和的度量列 gross_amount Decimal64(2), discount_amount Decimal64(2), net_pay_amount Decimal64(2), refund_amount Decimal64(2), order_count UInt32, refund_count UInt32 ) ENGINE SummingMergeTree((gross_amount, discount_amount, net_pay_amount, refund_amount, order_count, refund_count)) PARTITION BY toYYYYMM(stat_date) ORDER BY (merchant_id, channel_code, currency, stat_date);查询时的核心军规为什么仍然必须写SUM()这是新手使用SummingMergeTree最容易产生的认知误区“既然引擎已经帮我把数据累加求和了那我查询时是不是可以直接写SELECT gross_amount FROM ...而不需要写SUM(gross_amount)了”绝对不行答案是必须依然显式写SUM()和GROUP BY原因在于合并的异步性ClickHouse 的后台合并是弱实时的。在两次查询之间可能有新写入的 Part 尚未与老 Part 完成物理合并。此时表内可能同时存在 3 个尚未折叠的相同维度行。维度上卷Rollup虽然底表按stat_date每天聚合但当业务查询“季度总额”时仍然需要将 90 天的日聚合行进一步累加。-- ✅ 正确的查询写法极速扫描已经高度折叠的数据块并做最终轻量汇总 SELECT merchant_id, sum(gross_amount) AS total_gross, sum(net_pay_amount) AS total_net, sum(order_count) AS total_orders FROM dws_merchant_daily_financial_summary WHERE merchant_id 8848 AND stat_date 2026-01-01 AND stat_date 2026-08-31 GROUP BY merchant_id;性能表现由于底表中的行数已经由 50 亿行明细压缩为了几百万行日汇总ClickHouse 执行上述SUM()时只需要扫描几 MB 数据耗时从5 秒暴降至 8 毫秒实现真正的亚秒级极速响应SummingMergeTree 的三大限制与避坑底线绝对无法计算非数值与唯一值COUNT DISTINCTSummingMergeTree只能做简单的数值相加。如果你需要统计日去重人数UV不能用SummingMergeTree必须使用带有AggregateFunction(uniqExact, ...)的AggregatingMergeTree。复合指标不能直接相加平均值avg_price、转化率cvr属于非可加性度量Non-Additive Metrics绝对不能直接作为 SummingMergeTree 的累加列。正确的做法是分别存储分子sum(pay_amount)和分母sum(order_count)在最外层查询中做动态除法计算sum(pay_amount) / NULLIF(sum(order_count), 0)。主键维度设计越精简压缩比越高ORDER BY中的字段决定了数据的聚合粒度。如果把一个高基数的随机 UUID 放进了ORDER BY中每行数据的主键都互不相同SummingMergeTree将完全失去折叠效果退化为普通的大表。在数仓架构中明细归明细汇总归汇总。善用SummingMergeTree作为高频大屏与报表的预聚合加速底座是让分析系统在高并发下坚如磐石的核心保障。
SummingMergeTree 在聚合指标中的秒级响应：放弃明细全表扫描的终极方案
SummingMergeTree 在聚合指标中的秒级响应放弃明细全表扫描的终极方案在设计高吞吐、高并发的企业级财务对账、流量统计和广告结算看板时最耗费计算资源的度量永远是基础数值的求和SUM(amount)、SUM(clicks)、SUM(views)。很多团队在把数据接入 ClickHouse 时习惯性地把所有事件明细全塞进标准的MergeTree引擎里。当单表记录数达到 50 亿行、历史跨度长达 2 年时业务端只要在页面上拉一个“按商户查看近 1 年月度总流水”的报表ClickHouse 哪怕利用多核并发全速扫描也需要从磁盘读取数十 GB 的压缩数据单次查询耗时在 3~8 秒左右。一旦周一早高峰几十个运营同时打开大屏数据库 CPU 直接被打到 100%。对于这种只关心数值累加、无需回溯单笔明细的业务场景ClickHouse 提供了原生的预聚合引擎——SummingMergeTree。它能够在后台异步合并数据片段Part时自动将具有相同排序键ORDER BY的数值列进行代数求和压缩将物理存储和扫描行数直接降低两个数量级。SummingMergeTree 的工作原理物理行自动折叠在标准MergeTree中每插入一条包含相同主键的流水磁盘上就会新增一行而在SummingMergeTree中后台合并线程Merge会自动将相同排序键的行进行合并把指定的数值列累加从而实现物理行数的“自动折叠”。[ 批次 1 写入 ] [ 批次 2 写入 ] (2026-09-03, 门店A, 商品X, 销售额: 100, 订单数: 2) (2026-09-03, 门店A, 商品X, 销售额: 50, 订单数: 1) \ / ▼ ▼ [ 后台触发 SummingMergeTree Compaction 归并折叠 ] ↓ (2026-09-03, 门店A, 商品X, 销售额: 150, 订单数: 3) -- 物理压缩为 1 行建表实战财务汇总表的设计与列定义创建SummingMergeTree时可以显式在括号内声明需要累加的列列表。如果省略括号ClickHouse 会默认将所有非主键的数值类型UInt*,Int*,Float*,Decimal*字段全部作为累加列CREATE TABLE dws_merchant_daily_financial_summary ( stat_date Date, merchant_id UInt32, channel_code LowCardinality(String), currency LowCardinality(String), -- 声明需要自动累加求和的度量列 gross_amount Decimal64(2), discount_amount Decimal64(2), net_pay_amount Decimal64(2), refund_amount Decimal64(2), order_count UInt32, refund_count UInt32 ) ENGINE SummingMergeTree((gross_amount, discount_amount, net_pay_amount, refund_amount, order_count, refund_count)) PARTITION BY toYYYYMM(stat_date) ORDER BY (merchant_id, channel_code, currency, stat_date);查询时的核心军规为什么仍然必须写SUM()这是新手使用SummingMergeTree最容易产生的认知误区“既然引擎已经帮我把数据累加求和了那我查询时是不是可以直接写SELECT gross_amount FROM ...而不需要写SUM(gross_amount)了”绝对不行答案是必须依然显式写SUM()和GROUP BY原因在于合并的异步性ClickHouse 的后台合并是弱实时的。在两次查询之间可能有新写入的 Part 尚未与老 Part 完成物理合并。此时表内可能同时存在 3 个尚未折叠的相同维度行。维度上卷Rollup虽然底表按stat_date每天聚合但当业务查询“季度总额”时仍然需要将 90 天的日聚合行进一步累加。-- ✅ 正确的查询写法极速扫描已经高度折叠的数据块并做最终轻量汇总 SELECT merchant_id, sum(gross_amount) AS total_gross, sum(net_pay_amount) AS total_net, sum(order_count) AS total_orders FROM dws_merchant_daily_financial_summary WHERE merchant_id 8848 AND stat_date 2026-01-01 AND stat_date 2026-08-31 GROUP BY merchant_id;性能表现由于底表中的行数已经由 50 亿行明细压缩为了几百万行日汇总ClickHouse 执行上述SUM()时只需要扫描几 MB 数据耗时从5 秒暴降至 8 毫秒实现真正的亚秒级极速响应SummingMergeTree 的三大限制与避坑底线绝对无法计算非数值与唯一值COUNT DISTINCTSummingMergeTree只能做简单的数值相加。如果你需要统计日去重人数UV不能用SummingMergeTree必须使用带有AggregateFunction(uniqExact, ...)的AggregatingMergeTree。复合指标不能直接相加平均值avg_price、转化率cvr属于非可加性度量Non-Additive Metrics绝对不能直接作为 SummingMergeTree 的累加列。正确的做法是分别存储分子sum(pay_amount)和分母sum(order_count)在最外层查询中做动态除法计算sum(pay_amount) / NULLIF(sum(order_count), 0)。主键维度设计越精简压缩比越高ORDER BY中的字段决定了数据的聚合粒度。如果把一个高基数的随机 UUID 放进了ORDER BY中每行数据的主键都互不相同SummingMergeTree将完全失去折叠效果退化为普通的大表。在数仓架构中明细归明细汇总归汇总。善用SummingMergeTree作为高频大屏与报表的预聚合加速底座是让分析系统在高并发下坚如磐石的核心保障。