必须把嵌套查询改成join当子查询出现在where或select中且为标量子查询时，因数据库难优化、易索引失效、多行报错；in子查询在mysql 5.6及更早版会生成临时表不走索引；相关子查询需提前聚合并用left join+coalesce，避免行数膨胀和null逻辑错误。
什么时候必须把嵌套查询改成JOIN
当子查询出现在 WHERE 或 SELECT 子句里，且它只查一个值（比如 (SELECT name FROM users WHERE id = orders.user_id)），这种标量子查询虽然能跑，但多数数据库无法高效利用索引，尤其在大表上会明显变慢。更麻烦的是，如果子查询返回多行（比如漏写了 WHERE 条件），直接报错 Subquery returns more than 1 row，而 JOIN 天然规避这个问题。
IN子查询改写为INNER JOIN的典型陷阱
写成 WHERE order_id IN (SELECT order_id FROM order_items) 看似简洁，但 MySQL 5.6 及更早版本会把子查询转成临时表，不走索引；PostgreSQL 则可能生成嵌套循环。改成 JOIN 更可控：
- 先确认子查询结果是否去重——
IN语义等价于DISTINCT，所以 JOIN 前得加DISTINCT或用EXISTS - 如果原查询本意是“只要存在匹配就保留主表行”，用
INNER JOIN即可；但如果主表行必须全部保留（哪怕没匹配），就得换成LEFT JOIN+IS NOT NULL过滤 - 注意字段别名冲突：JOIN 后两个表都有
id，引用时必须写成orders.id或加AS别名
相关子查询（含外部引用）怎么安全转JOIN
像 SELECT *, (SELECT COUNT(*) FROM order_items oi WHERE oi.order_id = o.id) item_count FROM orders o 这种，子查询依赖外层 o.id，不能简单扔掉。正确做法是把子查询提前聚合：
SELECT o.*, COALESCE(oi.item_count, 0) AS item_count FROM orders o LEFT JOIN ( SELECT order_id, COUNT(*) AS item_count FROM order_items GROUP BY order_id ) oi ON oi.order_id = o.id
关键点：
- 子查询必须
GROUP BY外层关联字段，否则 JOIN 后会爆炸式膨胀 - 用
LEFT JOIN保证主表行不丢失，配合COALESCE处理空值 - 如果原子查询有复杂条件（如
WHERE status = 'shipped'），必须挪到子查询内部，不能放在外层ON条件里——否则逻辑错误
性能差异到底在哪
JOIN 是声明式操作，优化器能基于统计信息选择哈希连接、归并连接或嵌套循环；而相关子查询强制按行执行，每查一行都重新跑一次子查询。实测过一个 10 万行订单表，标量子查询耗时 8.2 秒，等价 JOIN 仅 0.3 秒。但要注意：如果子查询本身极轻量（比如查单个配置值），强行 JOIN 可能增加解析开销，反而不如原写法。
真正容易被忽略的是 NULL 处理——IN (subquery) 遇到子查询结果含 NULL 时整个条件判 false，而 JOIN 会因 NULL 不匹配直接丢行，行为不等价，改写前务必验证业务语义。
