MySQL子查询易变慢因优化器难下推，常致重复执行、全表扫描；IN/JOIN改写需加DISTINCT和联合索引，标量子查询应先分组聚合再LEFT JOIN；非相关且快的子查询或含LIMIT/强相关的不宜硬改。
为什么子查询在 MySQL 里容易变慢
MySQL 对大多数非相关子查询（尤其是 WHERE ... IN (SELECT ...) 或 WHERE ... = (SELECT ...)）的执行计划不友好，常导致重复执行、临时表、全表扫描。5.7 之前版本尤其明显：优化器很难把子查询“下推”成等价 JOIN，结果就是外层每查一行，子查询可能跑一遍。
常见错误现象：EXPLAIN 显示 type 是 ALL 或 index，Extra 出现 Using temporary、Using filesort，甚至 Dependent subquery —— 最后这个说明子查询被当成相关子查询反复调用。
- 相关子查询必须逐行求值，无法提前物化
-
IN (SELECT ...)在数据量大时，MySQL 可能放弃使用索引，转而走哈希匹配或嵌套循环 - 子查询返回多行但外层只预期单值（比如
=），会直接报错Subquery returns more than 1 row
怎么把 WHERE IN 子查询改成 JOIN
核心是把“查出 A 表中满足 B 表某条件的记录”这种逻辑，从“先算出 B 的结果集，再过滤 A”变成“A 和 B 直接关联，用索引驱动连接”。前提是两个表有明确关联字段，且 B 表的筛选条件能下推到 ON 子句或 JOIN 后的 WHERE。
示例原语句：
SELECT id, name FROM user WHERE id IN (SELECT user_id FROM order WHERE status = 'paid');
改写为：
SELECT DISTINCT u.id, u.name FROM user u INNER JOIN order o ON u.id = o.user_id WHERE o.status = 'paid';
- 必须加
DISTINCT（或GROUP BY），否则一个用户多笔订单会导致重复行 -
INNER JOIN隐含了“存在对应订单”，和IN语义一致；若需保留无订单的用户，改用LEFT JOIN ... WHERE o.user_id IS NOT NULL - 确保
order(user_id, status)有联合索引，否则o.status = 'paid'可能触发全表扫描
标量子查询（WHERE ... = (SELECT ...)）怎么安全替换
这类子查询要求返回至多一行一列，改写为 JOIN 更需谨慎：不能简单用 INNER JOIN，否则会丢失主表中无匹配的记录；也不能直接 LEFT JOIN 后取字段，因为可能存在多匹配导致结果不唯一。
原语句：
SELECT id, name, (SELECT MAX(create_time) FROM login_log WHERE user_id = user.id) AS last_login FROM user;
正确改写（用聚合 + LEFT JOIN）：
SELECT u.id, u.name, l.max_time AS last_login FROM user u LEFT JOIN (SELECT user_id, MAX(create_time) AS max_time FROM login_log GROUP BY user_id) l ON u.id = l.user_id;
- 子查询必须先按
user_id分组聚合，把多行压成一行，再 JOIN，否则LEFT JOIN仍会膨胀 - 如果
login_log没有对应记录，l.max_time自然为NULL，语义和原标量子查询一致 - 避免写成
LEFT JOIN login_log ... GROUP BY u.id—— 这会让聚合跨主表和从表，逻辑错乱且性能差
什么时候不该硬改子查询为 JOIN
不是所有子查询都适合改。强行 JOIN 可能引入语义偏差、空值处理复杂化，或让执行计划更差。
- 子查询带
LIMIT 1且外层是=，例如WHERE x = (SELECT y FROM t ORDER BY z DESC LIMIT 1)：这种依赖排序+截断，JOIN 很难等价表达，不如保持子查询 + 给t(z, y)加索引 - 子查询用到了外层字段做计算（如
WHERE id > (SELECT AVG(id) FROM user2 WHERE type = user.type)），属于强相关子查询，改 JOIN 成本高、可读性差 - 子查询本身极快（如查配置表、缓存表，
rows恒为 1），改 JOIN 反而增加连接开销
真正关键的不是“能不能改”，是看 EXPLAIN 里子查询是否成了瓶颈节点。很多所谓“慢子查询”，其实缺的是索引，而不是结构问题。
