为何SQL执行子查询时速度很慢该如何优化

子查询慢主因是相关子查询导致嵌套循环放大，EXPLAIN显示DEPENDENT SUBQUERY即需优化：检查rows是否远超结果数、type是否为ALL/index且Extra含Using temporary等，确保子查询WHERE字段有合适联合索引，并依硬约束将IN/EXISTS改JOIN，标量子查询须提前聚合。

子查询慢，绝大多数时候不是写法问题，而是执行模型被拖垮了——相关子查询会让数据库为外层每一行重复执行一次内层逻辑，10万行主表就等于执行10万次子查询。

EXPLAIN 里看到 DEPENDENT SUBQUERY 就该立刻停手

这是最直接的信号，说明子查询依赖外层字段（比如 WHERE id IN (SELECT user_id FROM logs WHERE user_id = users.id)），优化器无法提前物化或下推条件。此时：

• 检查 rows 列：如果远大于实际结果数（比如显示扫描 80 万行，但只返回 200 行），基本确认是嵌套循环放大
• 看 type：若为 ALL 或 index，且 Extra 出现 Using where; Using temporary; Using filesort，说明没走索引、还建了临时表
• 确认子查询中 WHERE 条件字段是否有联合索引：例如子查询是 WHERE user_id = ? AND status = 'error'，必须有 (user_id, status) 索引，单列索引无效

IN/EXISTS 子查询改 JOIN 的三个硬约束

不是所有 IN 都能无脑换成 JOIN，漏掉任一约束都会出错：

• 子查询结果含 NULL 时，NOT IN 会永远返回空——必须用 LEFT JOIN ... WHERE right.id IS NULL，且加 AND right.id IS NOT NULL 显式排除 NULL
• 主表和子表是一对多关系（如一个用户有多条订单），直接 INNER JOIN 会导致主表行数膨胀——要么加 DISTINCT，要么改用 EXISTS
• 子查询带 ORDER BY + LIMIT 1（如取每个用户的最新订单）不能直接 JOIN——得先用派生表或窗口函数聚合，再关联

标量子查询（SELECT 单值）必须提前聚合

像 SELECT id, (SELECT COUNT(*) FROM logs WHERE user_id = u.id) AS log_count FROM users u 这种，本质是“每行触发一次聚合”，开销极大：

• 正确做法是把子查询提前算好：先 SELECT user_id, COUNT(*) AS cnt FROM logs GROUP BY user_id，再 LEFT JOIN 回主表
• 避免在子查询里用 WHERE 引用主表字段做条件过滤——这又变回相关子查询
• 如果聚合结果量很大（比如日志表上亿行），考虑加时间范围过滤（WHERE create_time > DATE_SUB(NOW(), INTERVAL 7 DAY)）再聚合

真正难的不是怎么改写，而是判断哪一层括号在执行时会触发重复计算——很多 SQL 看似简洁，实则藏着指数级扫描。改完之后，务必用 EXPLAIN 对比 rows 和 Extra 字段，而不是只看执行时间。时间可能受缓存干扰，但扫描行数不会说谎。