MySQL不建议用子查询主因是5.7及更早版本优化器对相关子查询缺乏物化能力，常每行外层重复执行，导致嵌套循环、高I/O与临时表滥用；应优先改写为JOIN或EXISTS并确保语义等价、索引到位、NULL可控。
MySQL不建议用子查询，不是因为它语法错，而是执行器在5.7及更早版本里对多数相关子查询（correlated subquery）缺乏有效优化能力——它常把子查询当成“黑盒”，每行主表都重新执行一次，而不是物化结果复用。
为什么相关子查询容易变慢
典型现象是 EXPLAIN 显示 type 为 ALL 或 index，Extra 出现 Using where; Using temporary; Using filesort，且 rows 列远超实际返回行数。
- 子查询若带
WHERE o.user_id = u.id这类外层引用，MySQL 5.7 很难下推条件，导致对主表每行都触发一次子查询扫描 - 即使子查询加了
LIMIT 1，优化器也不一定识别为半连接（semi-join），需显式改写或加/*+ SEMIJOIN() */提示 - 子查询返回多列或多行时，中间结果无法缓存，反复计算；而 JOIN 可走 Hash Join 或 Index Nested-Loop，支持提前过滤
哪些子查询能安全改写为JOIN
改写前必须确认语义等价，否则结果可能出错。可直接替换的常见模式：
-
WHERE id IN (SELECT user_id FROM logs WHERE status = 'error')→ 改为INNER JOIN logs ON o.id = logs.user_id AND logs.status = 'error' -
WHERE NOT EXISTS (SELECT 1 FROM order_items i WHERE i.order_id = o.id)→ 改为LEFT JOIN order_items i ON o.id = i.order_id WHERE i.order_id IS NULL，但要确保i.order_id不为NULL，否则逻辑失效 -
SELECT (SELECT name FROM users u WHERE u.id = o.user_id) AS username→ 改为LEFT JOIN users u ON o.user_id = u.id，再取u.name
改写时最容易踩的三个坑
很多性能没提升反而更差，问题就出在这几个细节上：
- 连接字段没索引：
o.user_id和u.id都得有单独索引或联合索引，否则 JOIN 会退化成全表嵌套循环 - 忽略 NULL 处理：
NOT IN (SELECT x FROM t)在子查询含NULL时整个条件恒为FALSE，但LEFT JOIN ... IS NULL不具备这种语义，必须加AND t.x IS NOT NULL - 没控住行数膨胀：比如订单表
orders和订单项order_items是一对多，直接JOIN后查orders.*会重复多行，得加DISTINCT orders.*或改用EXISTS
真正难的不是语法改写，是判断「这个子查询到底能不能搬出来」——要看它是否依赖外层值、是否聚合、是否允许 NULL、是否一对多。漏掉其中任一条件，结果就不可信。
