子查询统计慢的核心原因是执行计划不合理、重复计算、缺索引或嵌套过深；应优先用JOIN替代相关子查询、窗口函数替代同表聚合、CTE提取非相关子查询，并确保关键字段有合适索引。
子查询统计慢，核心问题往往出在执行计划不合理、重复计算、缺少索引或嵌套过深。改写关键不是简单“去掉子查询”，而是让数据库能高效利用索引、减少扫描行数、避免多次执行相同逻辑。
用 JOIN 替代相关子查询（最常见提速点）
相关子查询（即子查询中引用了外层表字段）每行都会触发一次执行，数据量大时性能断崖式下降。多数场景可转为 LEFT JOIN + 聚合。
例如原SQL：
SELECT a.order_id, a.user_id,(SELECT COUNT(*) FROM order_items b WHERE b.order_id = a.order_id) AS item_cnt
FROM orders a;
改写为：
SELECT a.order_id, a.user_id, COALESCE(b.item_cnt, 0) AS item_cntFROM orders a
LEFT JOIN (
SELECT order_id, COUNT(*) AS item_cnt
FROM order_items
GROUP BY order_id
) b ON a.order_id = b.order_id;
- 子查询只执行一次，结果集按 order_id 建好哈希表或排序归并
- 确保 order_items.order_id 有索引（最好是联合索引覆盖查询字段）
- 用 COALESCE 处理 NULL，语义与原 COUNT(*) 一致
用窗口函数替代聚合子查询（适用于同表分组统计）
当子查询只做本表内分组聚合（如查每个用户的订单总数），窗口函数几乎零成本，无需关联。
原SQL：
(SELECT COUNT(*) FROM orders b WHERE b.user_id = a.user_id) AS user_order_cnt
FROM orders a;
改写为：
SELECT user_id, order_id, amount,COUNT(*) OVER (PARTITION BY user_id) AS user_order_cnt
FROM orders a;
- 避免对每行重复扫描 orders 表，一次全表扫描即可完成统计
- 若只需部分用户，先 WHERE 过滤再开窗，效果更佳
- 注意：窗口函数不能替代需要关联其他表的子查询
提取子查询为 WITH 公共表表达式（CTE）
非相关子查询（不依赖外层表）若被多处引用，直接写多次会导致重复执行。用 WITH 预计算一次，后续直接复用。
原SQL（子查询被用了两次）：
SELECT * FROM ordersWHERE user_id IN (SELECT user_id FROM users WHERE status = 'active')
AND order_id IN (SELECT order_id FROM order_items WHERE qty > 10);
改写为：
WITH active_users AS (SELECT user_id FROM users WHERE status = 'active'
), big_orders AS (
SELECT DISTINCT order_id FROM order_items WHERE qty > 10
)
SELECT * FROM orders
WHERE user_id IN (SELECT user_id FROM active_users)
AND order_id IN (SELECT order_id FROM big_orders);
- CTE 在支持物化的数据库（如 PostgreSQL、SQL Server）中会真实缓存中间结果
- MySQL 8.0+ 也支持 CTE，但需确认是否启用物化（可通过 EXPLAIN 判断）
- CTE 不是视图，不建索引，所以子查询本身仍需优化（如加索引、缩小范围）
检查并补全关键索引（改写无效时的必查项）
再好的改写也架不住没索引。子查询变慢，90% 和索引缺失强相关。重点检查：
- 子查询中的 WHERE 条件字段 是否有索引（如 order_items.order_id、users.status）
- JOIN 或 IN 子句中用于匹配的字段是否为前导列（如联合索引 (status, user_id) 对 WHERE status = ? 有效，但对 WHERE user_id = ? 无效）
- 聚合子查询的 GROUP BY 字段 是否有索引（加速分组和排序）
- 考虑覆盖索引：把 SELECT 中用到的字段也加入索引，避免回表
