先执行SELECT key, COUNT(*) AS cnt FROM table GROUP BY key ORDER BY cnt DESC LIMIT 10定位top热点key，若首行cnt超次行10倍即为倾斜源；再结合Web UI查shuffle write最大stage反推SQL片段，Hive可启用hive.groupby.skewindata=true辅助识别。
GROUP BY 出现单个 task 卡死，怎么快速定位倾斜 key
先别急着改 SQL，直接查哪几个 key 在拖后腿。执行 SELECT key, COUNT(*) AS cnt FROM table GROUP BY key ORDER BY cnt DESC LIMIT 10，看 top 10 的分布——如果第一行的 cnt 是第二行的 10 倍以上，基本就是它了。
注意：别只看 EXPLAIN，有些引擎（如 Spark）得结合 Web UI 查 shuffle write 最大的那个 stage，再反推对应 SQL 片段；Hive 可开 hive.groupby.skewindata=true 后观察日志里有没有 “skew join detected” 类提示。
常见陷阱：
- 用
COUNT(DISTINCT user_id)查倾斜时，可能掩盖真实分布——它不暴露单个 key 的频次，得换回COUNT(*)+GROUP BY - 抽样统计（如
LIMIT 100000）可能漏掉长尾热点，尤其当数据按时间有序写入时，新数据集中在末尾
Hive/Spark 中对倾斜 key 加盐（Salting）的实际写法
加盐不是随便拼个随机数，关键在“可逆”和“可控”。假设已知 user_id = '0' 是脏数据热点，目标是把它打散到 20 个子组里再聚合：
SELECT
user_id,
SUM(cnt) AS total_cnt
FROM (
SELECT
CASE WHEN user_id = '0'
THEN CONCAT('salt_', FLOOR(RAND() * 20), '_', user_id)
ELSE user_id
END AS user_id,
COUNT(*) AS cnt
FROM logs
GROUP BY
CASE WHEN user_id = '0'
THEN CONCAT('salt_', FLOOR(RAND() * 20), '_', user_id)
ELSE user_id
END
) t
GROUP BY user_id;要点：
-
RAND()在 Hive 中每次调用结果不同，但同一行内多次调用值一致；Spark SQL 中需用rand(123)指定 seed 才可复现 - 盐值范围选 10–50 较稳妥：太小（如 2）仍可能倾斜，太大（如 1000）会让小 key 也拆太碎，增加调度和 merge 开销
- 别对所有 key 都加盐——只处理确认的 top 热点，否则反而降低局部性、拖慢非倾斜路径
JOIN 后再 GROUP BY 导致中间结果爆炸，怎么提前压降
典型场景：behavior JOIN user_dim ON behavior.user_id = user_dim.user_id GROUP BY user_dim.city。如果北上广用户占 60%，JOIN 后这三地行为记录会全挤在一个 reduce 里。
正确做法是把聚合下推到 JOIN 前：
- 先对行为表按
user_id聚合：算出每个用户的点击总数、首次时间等指标 - 再 JOIN 用户维度表，把
user_id映射成city - 最后按
city汇总——此时每行是「城市+单用户指标」，数据量远小于原始行为流
如果必须保留明细（比如要算城市内用户点击的中位数），且城市维度稳定，优先建物化视图：CREATE MATERIALIZED VIEW city_daily_stats AS SELECT city, COUNT(*), AVG(clicks) FROM ... GROUP BY city，避免每次查询都重跑大 JOIN。
索引对 GROUP BY 性能的影响常被高估
给 GROUP BY 字段建 B-tree 索引，在分析型查询里大概率没用，甚至更慢。比如对只有两个值的 status 字段建索引，数据库发现走索引要随机读几万页，不如直接全表扫描 + Hash Aggregate 快。
真正该关注的是：
- JOIN 条件字段是否有索引？没有的话，JOIN 本身就成了瓶颈，倾斜只是表象
- 分区字段是否和
GROUP BY字段一致？比如表按dt分区却按region分组，引擎无法剪枝，只能全表 shuffle - 倾斜 key 是否来自 NULL 或默认值（如
user_id = 0）？这类值往往没业务意义，ETL 层就该清洗掉，而不是留到查询时硬扛
复杂点在于：加盐、预聚合、分离热点这几种策略很少单独生效。实际线上 case 通常要组合——比如先用子查询把 user_id IS NULL 拆出来单独处理，剩下的再对高频 user_id 加盐，最后 UNION ALL。漏掉任意一环，都可能让优化效果打五折。
