join本身不快，快的是它让优化器能避免对外层每行重跑子查询；相关子查询未优化时会触发50万次内层执行，explain中type=dependent subquery是危险信号，需通过on条件、索引、字符集一致等确保优化器有效决策。
JOIN 本身不快，快的是它让优化器能避免“对外层每行都重跑一次子查询”——而 Correlated 子查询（相关子查询）在没被优化时，就是这么干的。
看到 EXPLAIN 里 type=DEPENDENT SUBQUERY 就该立刻干预
这是 MySQL 和 PostgreSQL 执行计划中最危险的信号之一。它不是说“用了子查询”，而是明确告诉你：外层表当前这一行，会触发一次完整的内层查询执行。
常见错误现象：
- users 表有 50 万行，
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)实际执行约 50 万次索引查找（哪怕orders.user_id有索引） -
EXPLAIN输出中select_type列显示DEPENDENT SUBQUERY，且rows很小但loops极大（如loops=48231） - Extra 列出现
Using where; Using index却耗时严重——说明不是扫描慢，是调度和上下文切换开销大
JOIN 能让优化器一次性规划，但前提是条件写对
Correlated 子查询是“分步执行”，JOIN 是“全局决策”。但这个优势不会自动生效，得靠你把逻辑塞进优化器能识别的结构里。
关键实操建议：
- 把过滤条件尽量放进
ON子句而非WHERE，例如：JOIN orders o ON u.id = o.user_id AND o.status = 'paid'，这样优化器才可能用到(user_id, status)联合索引 - 避免在子查询里写
GROUP BY、LIMIT或ORDER BY——这些会直接让 MySQL 5.6+ 的 semi-join 优化失效，退回到嵌套循环 - 确认连接字段字符集一致，比如
utf8mb4对utf8会导致隐式转换，索引失效，JOIN 退化为全表比对 - 小表没被选为驱动表？MySQL 可加
STRAIGHT_JOIN强制，但必须先用EXPLAIN ANALYZE确认当前计划
改写后数据不对？大概率踩了语义坑
语法改了，语义没对齐，结果就错。这不是性能问题，是逻辑 bug。
最容易忽略的三点：
-
IN天然去重，INNER JOIN遇到一对多（一个用户多笔订单）会放大行数；需加DISTINCT或确认业务允许重复 - 原逻辑要查“没订单的用户”，却写了
INNER JOIN，直接漏掉全部数据；该用LEFT JOIN ... WHERE o.user_id IS NULL - 两表都有
id字段，SELECT * FROM users u JOIN orders o ON u.id = o.user_id会报Column 'id' in field list is ambiguous；必须显式写u.id或o.id
不是所有子查询都该换，标量的有时更轻量
当子查询返回单值、且能走索引快速定位时，它反而比 JOIN + GROUP BY 更省资源。
例如：
SELECT id, name, (SELECT MAX(created_at) FROM logs l WHERE l.user_id = u.id) FROM users u
只要 logs(user_id, created_at) 有索引，这个子查询每次只做一次索引 MAX 查找，开销极低。
而等价的 LEFT JOIN logs GROUP BY u.id 会先生成所有匹配行再聚合，中间结果集可能远大于用户数。
真正起作用的从来不是“用了 JOIN”，而是“JOIN 让优化器有了足够信息做全局决策”。别只改语法，盯着 EXPLAIN 里的 type、key、rows 和 Extra 看清楚到底扫了几行、用了什么索引、有没有临时表——这才是性能差异藏得最深的地方。
