SQL数据倾斜会严重干扰优化器决策，导致算子误选、并行负载不均、策略降级及索引失效，本质是分布假设被打破，需通过重统计、加盐、预聚合或hint修正。
SQL 数据倾斜会显著干扰优化器对执行计划的判断，导致选择低效甚至错误的算子和连接方式，进而引发性能雪崩。
统计信息失真，误导优化器决策
当某列（如用户ID、省份）存在严重倾斜，比如 1% 的值占了 90% 的行数，而优化器依赖的直方图或采样统计仍按均匀分布估算，就会严重低估高频值的匹配行数。例如，对倾斜键做 JOIN 时，优化器可能误判为小表关联，选用 Nested Loop，实际却要循环扫描数十万次重复键，远超预期开销。
并行任务负载不均，拖垮整体耗时
在分布式 SQL 引擎（如 Spark SQL、Presto、Flink SQL）中，Shuffle 阶段按 Join Key 或 Group By Key 分区。若 Key 倾斜，部分 Task 会处理远超平均的数据量，形成“长尾”。此时执行计划虽显示并行度正常，但真实运行中：
- 多数 Task 很快完成，空等少数慢 Task
- 资源利用率极低，CPU 和内存集中在少数节点
- 执行时间由最慢 Task 决定，整体响应变慢数倍甚至数十倍
触发非预期的执行策略降级
部分引擎在检测到 Shuffle 数据量异常时，会自动切换执行策略，反而降低效率。例如：
- 本该用 Broadcast Join 的场景，因倾斜 Key 导致广播表膨胀，引擎回退为 Sort-Merge Join
- 为规避数据倾斜而启用 Salting（加盐），但优化器未感知盐值逻辑，仍按原 Key 生成计划，造成冗余计算和额外 Shuffle
- 某些数据库（如 Hive）在 group by 倾斜时开启
hive.groupby.skewindata=true，会引入两阶段 MapReduce，增加中间落盘和调度开销
索引与分区失效，放大 I/O 开销
倾斜常使局部性假设失效。例如：
- 按用户 ID 分区的表，若少数超级用户产生海量记录，查询这些用户时会集中访问单一分区，其他分区闲置
- 在倾斜字段上建 B+ 树索引，范围查询可能命中大量重复值，导致索引深度突增、回表次数激增
- 谓词下推失效：优化器以为
WHERE user_id = 'U123'是点查，实际该 ID 对应百万行，全索引扫描变成“伪全表扫”
本质上，执行计划是基于数据分布假设的静态蓝图；数据倾斜打破了这个假设，让计划“纸上谈兵”。解决关键不在改写 SQL 形式，而在暴露并修正分布偏差——比如采样重统计、加盐打散、预聚合倾斜键、或用 skew join hint 显式引导优化器。
