GROUP BY倾斜主因有四：NULL值集中、JOIN后膨胀、分区键与分组键不匹配、低基数字段建索引反拖慢；应分别采用随机化NULL、聚合下推、调整分区、慎用索引等策略优化。
GROUP BY 字段存在大量 NULL 或重复值导致倾斜
NULL 值在大多数数据库中会被归为同一组，如果表里有上百万行 user_id 为 NULL，GROUP BY user_id 就会让一个 reducer（或执行线程）扛下全部 NULL 行，其他节点空转。MySQL、PostgreSQL、Spark SQL 都存在这个问题。
解决思路不是“过滤 NULL”，而是让 NULL 也分散开：
- 用
COALESCE(user_id, FLOOR(RAND() * 10000))把 NULL 映射成随机整数（适用于临时分析，注意RAND()在某些引擎中不可重复） - 更稳妥的做法是先用子查询把 NULL 单独拆出来，和其他分组 UNION ALL，避免混入主流程
- 如果业务允许，建表时把
user_id设为NOT NULL，用0或负数占位，再加注释说明含义
JOIN 后再 GROUP BY 引发中间结果爆炸
常见于“用户行为表 JOIN 用户维度表，再按城市统计点击量”。如果某城市有 10 万用户，每个用户平均产生 500 条行为，JOIN 后中间结果就是 5000 万行——远超原始行为表规模，GROUP BY 才刚开始就卡住。
优先把聚合下推到 JOIN 前：
- 先对行为表
GROUP BY user_id汇总单用户指标（如总点击、首次时间），再 JOIN 维度表映射城市 - 若必须按城市汇总，且城市维度稳定，可预计算城市级物化视图，避免每次查都重算
- 确认 JOIN 条件字段（如
user_id）是否有索引；没有的话，JOIN本身就会变慢，放大倾斜感知
分区键与 GROUP BY 字段不一致导致 shuffle 无意义打散
比如 Hive 表按 dt STRING 分区，但查询写的是 GROUP BY region，引擎无法利用分区剪枝，还得全表扫描 + 全局 shuffle。数据按天分布均匀，但按地区严重不均（北上广占 60%），shuffle 阶段必然倾斜。
优化方向取决于使用模式：
- 高频按
region聚合？考虑改成按region二级分区（PARTITIONED BY (dt STRING, region STRING)），加速定位 + 减少单任务数据量 - 无法改表结构？在 WHERE 中强制加入高基数过滤条件（如
AND dt = '2024-06-01'），缩小 shuffle 输入规模 - Spark SQL 可开启
spark.sql.adaptive.enabled=true，让运行时自动切分大 partition，但不能替代逻辑优化
单个 GROUP BY key 占比超 20%，索引反而可能拖慢查询
有人觉得“给 GROUP BY 字段加索引总没错”，但在分析型查询中常适得其反。比如对 status（只有 'active'/'inactive' 两个值）建 B-tree 索引，数据库可能放弃索引、改走全表扫描+Hash Aggregate——因为索引遍历成本高于直接读块。
判断是否该建索引，看三个事实：
- 该字段的 distinct count / total rows > 0.05？低于这个阈值，B-tree 索引大概率被忽略
- 查询是否带高选择性 WHERE（如
WHERE create_time > '2024-01-01'）？有则索引可用于快速定位子集，再聚合才有效 - 用
EXPLAIN看执行计划：如果出现Index Scan但实际耗时飙升，八成是索引放大了 I/O（尤其 OLAP 场景）
真正有效的索引往往是组合索引，例如 (dt, region, user_id)，既支持时间范围裁剪，又让 GROUP BY region 能利用索引有序性做流式聚合。
