子查询中出现using temporary和using filesort是数据倾斜的直接体现，需通过查热点key、改写为exists、加盐分桶、启用自动倾斜优化等手段解决。
子查询中出现 Using temporary 和 Using filesort 怎么办
这两个提示不是孤立警告，而是数据倾斜在执行计划里的直接体现：当子查询结果集分布严重不均（比如 90% 的关联值集中在 3 个 user_id 上），MySQL 不得不建临时表排序或分组，导致磁盘 IO 暴增。重点看 EXPLAIN ANALYZE 输出中该子查询节点的 rows 和 filtered——如果 rows 是预估百万级但实际只返回几十行，说明扫描浪费严重。
- 先确认是否真由倾斜引起：用
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 10查看 top10 热点 key - 避免在子查询里直接
GROUP BY或ORDER BY，它们会强制触发临时表；改用外层聚合或物化中间结果 - 若子查询用于
IN列表，且热点 key 占比 >15%，优先考虑拆分：把高频 user_id 单独查，其余走子查询再UNION ALL
MySQL 中 IN (SELECT ...) 因倾斜卡住怎么破
优化器对 IN 子查询默认采用物化策略，一旦子查询结果里存在大量重复值（如千万级订单表里 80% 订单属于 5 个 VIP 用户），物化过程本身就会成为瓶颈。此时 key 字段常为 NULL，type 显示 ALL，哪怕 orders.user_id 有索引也无效。
- 强制改写为
EXISTS：它不物化结果集，而是对主表每行做半连接探测，天然规避倾斜放大效应 - 加盐处理：对倾斜字段做哈希分桶，例如
CONCAT(user_id, '_', FLOOR(RAND()*10))，再在子查询和主表都应用相同逻辑 - 慎用
DISTINCT：子查询里加DISTINCT不解决根本问题，反而让优化器放弃索引下推，应先过滤再去重
Hive/Spark SQL 里子查询倾斜的典型表现
在分布式引擎中，子查询倾斜会直接表现为某个 reduce task 运行时间远超其他 task（如 99% 的 task 在 2 秒内完成，1 个卡在 300 秒），日志里频繁出现 java.lang.OutOfMemoryError: Java heap space 或 Too many bytes spilled to disk。这是因为倾斜 key 被分配到同一 partition，所有相关数据全挤进一个节点处理。
- 用
DISTRIBUTE BY打散热点：在子查询末尾加DISTRIBUTE BY hash(user_id)强制重分区 - 开启自动倾斜处理：Hive 设置
set hive.optimize.skewjoin=true;，Spark SQL 设置spark.sql.adaptive.enabled=true - 改写为 map join：若子查询结果可控制在 10MB 内，显式加
/*+ MAPJOIN(small_subq) */避免 shuffle
为什么把子查询改成 JOIN 后更慢了
这不是语法问题，而是语义失真。子查询天然具备“短路”特性（如 EXISTS 找到一行就退出），而 JOIN 必须产出所有匹配组合。一旦子查询中倾斜 key 对应的记录数爆炸（比如 1 个 user_id 关联 50 万订单），JOIN 就会把主表该行复制 50 万次，后续 GROUP BY 或 ORDER BY 成本呈指数增长。
- 检查改写后是否引入重复：用
SELECT COUNT(*)和SELECT COUNT(DISTINCT main_id)对比，差值过大即为膨胀 - 优先保留子查询逻辑，仅优化其内部结构：比如把
WHERE user_id IN (SELECT id FROM users WHERE status='active')拆成先查出 active user_ids 到临时表，再用IN查订单 - 真正需要
JOIN时，务必加DISTINCT或GROUP BY去重，且确保驱动表是小表
rows 数字异常高，而不会立刻意识到这是数据分布缺陷，不是 SQL 写法或索引缺失。
