分布式分组需先局部聚合以降低网络开销，SQL Server需显式引导（分片键参与过滤/分组、避免非聚合列、用DISTRIBUTED提示），StarRocks等MPP引擎默认支持但依赖分桶键匹配和配置启用，HAVING、窗口函数、COUNT(DISTINCT)易破坏局部聚合。
为什么分布式分组要先做局部聚合
因为跨节点传输原始行数据的开销远大于传输聚合后的中间结果。比如对 1 亿条订单按 product_id 统计数量，若直接把所有行发到协调节点再 GROUP BY，网络带宽和内存压力会爆炸；而每个节点先算出自己本地的 COUNT(*)，只传几千个 (product_id, count) 对，通信量可能下降 99% 以上。
SQL Server 中如何触发局部聚合
SQL Server 不会自动拆解 GROUP BY 做局部+全局两阶段，必须显式引导。关键点有三个：
- 分片键（如
OrderID或CustomerID）必须出现在WHERE或GROUP BY子句中，否则协调器无法下推聚合 - 避免在
SELECT中引用未分组的非聚合列，否则强制全量拉取 - 用
DISTRIBUTED查询提示或视图绑定策略，明确告诉优化器“这个表是分片的”
示例：假设 DistributedOrders 按 OrderID 哈希分片，下面语句能触发局部聚合：
SELECT product_id, SUM(local_count) AS total_count FROM ( SELECT product_id, COUNT(*) AS local_count FROM DistributedOrders WHERE OrderID % 4 = 0 -- 显式命中某一分区，让节点只处理自己数据 GROUP BY product_id ) t GROUP BY product_id;
StarRocks / Doris 等 MPP 引擎的局部聚合更友好
这类引擎默认启用两阶段聚合（LOCAL + GLOBAL），但需满足条件才能真正生效：
-
GROUP BY字段必须是分区分桶键的一部分，否则仍会退化为单节点聚合 - 不能有
ORDER BY或LIMIT在外层干扰执行计划，否则可能跳过局部阶段 - 开启
enable_local_shuffle_agg（StarRocks）或检查new_planner_agg_stage配置项是否为2
执行前务必用 EXPLAIN 确认 Plan 中出现 AGGREGATE (LOCAL) 和 AGGREGATE (GLOBAL) 两个节点，而不是只有后者。
容易被忽略的坑：HAVING 和窗口函数会破坏局部聚合
一旦用了 HAVING COUNT(*) > 100 或 ROW_NUMBER() OVER (...) ，大多数分布式数据库会放弃局部聚合路径——因为过滤或排序逻辑无法在本地完成判断，必须把原始数据全量上拉。
- 替代方案：把
HAVING条件尽量前移到WHERE，例如改写为WHERE order_status = 'completed'再聚合 - 窗口函数尽量用
PARTITION BY匹配分片键，否则极易触发广播或重分布 - 如果必须用
COUNT(DISTINCT)，注意它天然不支持局部合并，考虑用APPROX_COUNT_DISTINCT或预计算布隆过滤器
局部聚合不是开关一开就自动生效的机制，它高度依赖查询结构、数据分布和引擎配置三者的咬合。哪怕只多一个没走索引的 WHERE 条件，整个聚合链路就可能坍缩回单点计算。
