根本原因是分组键与分片键不一致导致中间结果跨网络反复搬运，需确保分组字段对齐分片规则并下推聚合至存储节点。
为什么GROUP BY在分布式库里容易卡住
根本原因不是函数本身慢，而是中间结果集在网络间反复搬运。单机上GROUP BY可能只做一次内存聚合；分布式环境下，如果分组键没对齐分片规则，每个节点先局部聚合，再把海量中间结果发到中心节点做全局合并——这时候ExecTime飙升、NumRegions暴涨，但执行计划里可能只显示一个平淡无奇的HashAgg。
- 典型症状：监控看到大量
RemoteScan或Exchange算子，CPU不高但网络带宽打满 - 最隐蔽的坑：分组字段和分片键不一致，比如按
user_id分片，却用region_code做GROUP BY - TiDB等系统默认走
HashAgg，一旦region_code倾斜（如80%数据集中在“华东”），局部聚合后仍要传几十GB到TiDB层
怎么让GROUP BY真正下推到存储节点
目标是让每个TiKV或Doris BE节点自己完成“过滤→聚合→返回”，避免中心节点成为瓶颈。这依赖两件事：索引能命中，且分组逻辑可被下推。
- WHERE条件必须能下推：别写
WHERE YEAR(created_at) = 2024，改用WHERE created_at >= '2024-01-01' AND created_at ，否则<code>Selection挂在顶层，全量数据先拉再筛 - 分组字段必须有索引，且类型严格匹配：比如
region_code是VARCHAR(32)，查询里传'east'就别隐式转成TEXT，否则索引失效 - 用
EXPLAIN FORMAT = 'VERBOSE'确认TableReader或IndexScan节点下是否包含GroupBy——如果有，说明下推成功；如果GroupBy在最外层，就是失败
复合索引怎么建才对聚合有效
不是“给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字段，宁可放弃覆盖，改用物化视图
什么时候该放弃实时聚合
当业务允许几秒到几分钟延迟时，硬扛分布式实时聚合往往是成本最高的选择。真正的优化常发生在SQL之外。
- 高频小范围聚合（如按小时统计订单）：用
MATERIALIZED VIEW（Doris/TiDB 7.5+）或定时任务预计算存到汇总表 - 去重计数（
COUNT(DISTINCT user_id)）：直接上HLL或APPROX_COUNT_DISTINCT，误差 - 分区表必须配时间字段：比如按
dt分区，WHERE dt = '2024-06-15'能自动裁剪，否则哪怕有索引也白搭 - 最易被忽略的一点：检查
ANALYZE TABLE是否定期执行——统计信息过期会导致优化器误判，选错执行路径，比没索引还危险
