关联子查询遇倾斜key会引发“热点放大”，即外层每行触发一次相同子查询，导致重复扫描、聚合和跨节点rpc；统计信息失真会加剧该问题，改写为join时须同步处理倾斜key打散与null语义。
关联子查询遇上倾斜 key：每行都触发一次“热点放大”
关联子查询本身是逐行代入执行的，当外层某几个 key（比如 user_id = 0 或 region = 'unknown'）在主表中出现数十万次，而子查询又依赖这个 key 做过滤或聚合时，数据库就会对同一个热点 key 反复执行完全相同的子查询逻辑——不是执行 1 次，而是执行 N 次，每次还可能触发全表扫描、重复索引查找、重复聚合计算。这比普通 JOIN 的数据倾斜更隐蔽：JOIN 至少还能靠 shuffle 分摊压力，而关联子查询把“热点放大”直接压在单节点、单线程上。
常见错误现象：EXPLAIN ANALYZE 显示子查询部分耗时占比超 95%，且 SubPlan 节点反复出现 Seq Scan on orders 或 Index Scan using idx_orders_user_id on orders ——但扫描的其实是同一组数据，只是被调用了几十万遍。
为什么统计信息失效会让倾斜雪上加霜
优化器判断是否物化子查询、是否走索引、甚至是否尝试半连接重写，全都依赖对“子查询结果集大小”的预估。如果 ANALYZE 没更新，或者采样率太低（如 MySQL 默认只采样 10%），它就可能把实际有 80 万行的 orders 表误判为只有 8 千行，进而认为“物化子查询不划算”，坚持用嵌套循环；或者低估 WHERE status = 'pending' 的选择率（实际占 99%），导致放弃联合索引 (user_id, status)，转而全表扫描。
- MySQL：用
ANALYZE TABLE orders WITH HISTOGRAM ON status补充直方图，尤其对高偏态字段 - PostgreSQL：对多列组合过滤（如
user_id, created_at）运行ANALYZE orders (user_id, created_at) - 不要依赖自动统计——大表上默认采样常严重失真
改写为 JOIN 后，倾斜逻辑没同步迁移
把 (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) 改成 LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) o ON users.id = o.user_id 看似合理，但如果 user_id 存在大量 NULL 或 0 值，原始子查询会返回 NULL（语义安全），而 JOIN 后的子查询 GROUP BY user_id 会把所有 NULL 归为一组，导致该组聚合结果被广播到所有匹配的外层行——瞬间产生百万级笛卡尔积，且无报错。
实操要点：
- 先查
SELECT user_id, COUNT(*) FROM users GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 5，确认是否存在倾斜值 - 若存在，JOIN 前必须对倾斜 key 单独处理：比如用
CASE WHEN user_id IS NULL THEN CONCAT('salt_', FLOOR(RAND(42) * 30)) ELSE user_id END打散 -
COALESCE(o.cnt, 0)必须显式补上，否则 NULL 语义丢失
TiDB 和 Spark SQL 的跨节点放大效应更致命
TiDB 中，关联子查询逐行代入会引发频繁跨 TiKV 节点 RPC；Spark SQL 中，每个 executor 都可能独立触发子查询，若子查询含全局聚合（如 AVG()），还会反复拉取全量数据。这两种场景下，“一次子查询 = 一次网络往返 + 一次远端扫描”，热点 key 出现 10 万次，就是 10 万次跨节点请求，网络开销直接压垮吞吐。
真正关键的不是“要不要去关联”，而是“去关联后，倾斜 key 的分发逻辑是否一致”。比如加盐时用 RAND() 而非 RAND(42)，会导致同一行在不同 stage 中生成不同盐值，JOIN 断裂；盐值范围选 5 而不是 30，无法有效打散，倾斜依旧。
