根本原因是分组键与分片键不一致导致中间结果跨节点反复搬运；需确保分组字段对齐分片规则、WHERE条件可下推、索引按过滤→分组→覆盖顺序设计，并通过EXPLAIN确认GroupBy是否下推至存储节点。
根本原因不是GROUP BY本身慢，而是分组键没对齐分片规则，导致中间结果跨节点反复搬运。
为什么GROUP BY在分布式库容易卡住
单机数据库做GROUP BY，通常一次内存聚合就完事；分布式环境下，如果分组字段和分片键不一致（比如按user_id分片，却用region_code分组），每个存储节点只能先做局部聚合，再把大量中间结果发到中心节点合并——这时候ExecTime飙升、NumRegions暴涨，但执行计划里可能只显示一个平淡无奇的HashAgg。
- 典型症状：监控看到大量
RemoteScan或Exchange算子，CPU不高但网络带宽打满 - 最隐蔽的坑：
region_code数据倾斜（如80%集中在“华东”），局部聚合后仍要传几十GB到TiDB层 - 别指望优化器自动识别——它默认走
HashAgg，不主动下推，除非你给足条件
怎么确认GROUP BY是否真正下推
目标是让每个TiKV或Doris BE节点自己完成“过滤→聚合→返回”，避免中心节点成为瓶颈。关键看执行计划里GroupBy出现在哪一层：
- 用
EXPLAIN FORMAT = 'VERBOSE'查执行计划 - 如果
GroupBy出现在TableReader或IndexScan节点内部，说明下推成功 - 如果
GroupBy挂在最外层，就是失败——所有原始数据先拉到中心节点再聚合 -
WHERE条件必须能下推：别写WHERE YEAR(created_at) = 2024，改用WHERE created_at >= '2024-01-01' AND created_at
复合索引怎么建才对聚合有效
不是“给GROUP BY字段加个索引”就行，得按数据访问路径组织字段顺序：先过滤，再分组，最后覆盖SELECT字段。
- 例子：
SELECT region, COUNT(*), AVG(salary) FROM emp WHERE dept = 'tech' GROUP BY region - 正确索引：
(dept, region, salary)——dept快速定位，region支撑分组排序，salary让AVG()免回表 - 错误做法：
(region, dept)（WHERE无法利用后置字段），或漏掉salary（每次都要回主表读取） - 注意：
salary是数值型还好，如果是TEXT字段，宁可放弃覆盖，改用物化视图
什么时候该放弃实时GROUP BY
当业务允许几秒到几分钟延迟时，硬扛分布式实时聚合往往是成本最高的选择。
- 高频小范围聚合（如按小时统计订单）：用
MATERIALIZED VIEW（Doris/TiDB 7.5+）或定时任务预计算存到汇总表 - 去重计数（
COUNT(DISTINCT user_id)）：直接上HLL（HyperLogLog）近似算法 - 真正容易被忽略的点：不是所有聚合都必须在SQL里做完——应用层合并简单查询的结果，有时比一条复杂SQL更稳更快
