子查询慢主因是相关子查询导致嵌套循环放大，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 字段，而不是只看执行时间。时间可能受缓存干扰，但扫描行数不会说谎。
