SQL数据倾斜本质是某些key数据量远超其他key，导致分布式计算负载不均；解决需先定位倾斜点并分析业务热点，再针对性采用加盐、预聚合或广播小表等策略优化。
SQL数据倾斜问题本质是某些键（key）的数据量远超其他键，导致计算任务在分布式环境中分配不均，个别节点负载过高、执行缓慢甚至失败。解决核心在于让数据分布更均衡，关键策略不是简单“打散”，而是结合业务逻辑和数据特征做针对性优化。
理解倾斜根源：先查再治
盲目优化容易适得其反。应先定位倾斜点：
- 通过执行计划或日志识别耗时长、Shuffle数据量大的Stage及对应Join/Group By字段
- 抽样统计目标字段的Top N高频值（如SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY COUNT(*) DESC LIMIT 10）
- 确认是否为业务固有热点（如“用户ID=0”代表未登录用户、“商品类目=’手机’”流量集中）
加盐（Salting）：对高频key做随机分散
适用于Join或Group By场景中存在少量超高频key的情况。原理是给key附加随机前缀，打散后并行处理，再合并结果：
- Join倾斜：对大表和小表的key都添加相同随机因子（如0~9），分别与10个副本Join，最后UNION ALL去重
- Group By倾斜：对key加随机后缀（如CONCAT(key, '_', FLOOR(RAND() * 10))），聚合后再按原key二次汇总
- 注意控制盐值数量——太少仍倾斜，太多增加Shuffle开销
预聚合+广播小表：减少Shuffle数据量
当倾斜由小表膨胀引起（如维度表被广播后与大表Join产生重复），可提前压缩小表信息：
- 对小表中高频key对应的多条记录做聚合（如将同一用户的多条标签合并为数组）
- 用MAP或STRUCT类型承载聚合结果，降低Join后膨胀倍数
- 若小表足够小（如/*+ BROADCAST(table_name) */）避免Shuffle
分离热点+分层处理：业务逻辑驱动优化
对无法打散的强业务热点（如“平台活动ID=1001”），应绕过通用逻辑单独处理：
- 将热点key数据拆出单独子查询，用MapReduce或专用逻辑处理
- 非热点数据走常规SQL路径，最后UNION结果
- 配合缓存（如Redis预存热点聚合结果）降低实时计算压力
数据分布均衡不是追求绝对均匀，而是让各节点负载差异可控。真正有效的方案往往组合使用：先识别、再分离、辅以加盐和预聚合，同时关注业务语义而非仅技术指标。
