SQL数据倾斜本质是某些键值数据量远超其他键值导致分布式计算负载不均，解决需识别倾斜键、打散热点、平衡负载；可通过统计分布、EXPLAIN分析定位，用加盐、广播Join、动态调优等手段治理。
SQL数据倾斜本质是某些键值（key）的数据量远超其他键值，导致计算任务在分布式环境中严重不均衡，拖慢整体执行速度。解决核心在于识别倾斜键、打散热点、平衡负载。
识别倾斜键：从执行计划和日志入手
多数大数据引擎（如Spark SQL、Flink SQL、Hive）会在任务监控页面或日志中暴露数据倾斜迹象，例如某个task运行时间远长于其他task、shuffle write量异常高。可结合以下SQL辅助定位：
- 统计各分组键的记录数分布：SELECT key, COUNT(*) AS cnt FROM table GROUP BY key ORDER BY cnt DESC LIMIT 10;
- 观察count(distinct)与count(*)比值是否极低——说明少数key占绝大多数记录
- Hive/Spark中启用EXPLAIN EXTENDED查看物理执行计划，关注Shuffle阶段的key分布估算
加盐（Salting）：打散热点key的经典手段
对倾斜key单独处理：给key随机附加前缀（“盐”），把原key拆成多个子key并行处理，最后再聚合。适用于group by、join等场景。
- 步骤一：识别出top N倾斜key（如user_id = '12345'），用子查询或临时表标记
- 步骤二：对这些key做concat(rand(100), '_', key)生成新key；对非倾斜key保持原key不变
- 步骤三：按新key分组/关联，再按原始key二次聚合（如sum后按key合并）
- 注意：盐值范围不宜过大（如0–10），否则小key也被过度拆分，增加调度开销
大小表Join优化：广播+过滤前置
当大表与小表join出现倾斜，优先考虑Broadcast Join；若小表本身含倾斜key，需先过滤或重分布。
- 确保小表足够小（如set spark.sql.autoBroadcastJoinThreshold=10485760;
- 若小表存在热点key，先用WHERE key NOT IN (select key from big_table group by key having count(*) > threshold)剔除或单独处理
- 对大表中对应倾斜key的记录抽样分析，确认是否为脏数据（如默认值、空字符串），可在ETL层清洗
动态调整并行度与分区策略
静态分区易加剧倾斜，应结合数据特征动态适配。
- Spark中调大spark.sql.shuffle.partitions（如从200调至500+），避免单partition承载过多数据
- Hive中使用DISTRIBUTE BY hash(key) SORT BY key替代单纯GROUP BY，让哈希更均匀
- 对日期类key，避免直接按天分区导致月末/周一数据暴涨，可改用date + rand(10)二次分散
不复杂但容易忽略——数据倾斜不是“修bug”，而是数据认知过程。每次遇到都值得回溯上游数据质量、业务逻辑合理性，比如突然激增的测试账号、埋点重复上报、系统默认值滥用。真正治本，靠的是监控+治理+设计协同。
