left join 在多数场景下比子查询更可控、更可优化，尤其可避免 mysql 5.7 及更早版本中 dependent subquery 导致的 n+1 查询问题；但需注意语义对齐、null 处理及一对多膨胀等限制。
不是所有 LEFT JOIN 都比子查询快，但多数常见场景下，LEFT JOIN 更可控、更可优化。 关键不在“一定更快”，而在“更容易避开 MySQL 旧版优化器的坑”，尤其是当你看到 EXPLAIN 输出里出现 DEPENDENT SUBQUERY 时，基本就等于告诉自己：这句 SQL 正在做 N+1 查询。
看到 DEPENDENT SUBQUERY 就该立刻检查
这是最典型的性能红灯。只要子查询里引用了外层表字段（比如 u.id = o.user_id），MySQL 5.7 及更早版本几乎必然标记为 DEPENDENT SUBQUERY，导致主表每行都触发一次子查询执行。
- 订单表 10 万行？就是 10 万次解析 + 权限检查 + 临时表创建/销毁
- 哪怕子查询只返回单值（如
(SELECT name FROM users WHERE id = o.user_id)），也逃不开重复执行 -
EXPLAIN FORMAT=TREE能清晰看到嵌套层级，若节点含dependent subquery且Extra出现Using temporary; Using filesort，说明完全没物化
LEFT JOIN 的执行路径更透明、更可干预
JOIN 的执行策略（如 Index Nested-Loop Join）依赖索引明确，优化器行为稳定；而子查询是否被物化、是否转成 semi-join，高度依赖代价估算，有时连 EXPLAIN 都看不出区别。
- 驱动表小 + 被驱动表连接字段有索引 →
Index Nested-Loop Join效率极高 - LEFT JOIN 的 ON 条件位置明确，不会因写错地方（比如把右表过滤条件误放 WHERE）而意外退化成 INNER JOIN
- 你可以用
STRAIGHT_JOIN强制驱动顺序，但子查询没这种控制权 - 连接字段无索引时，LEFT JOIN 会直接暴露
type: ALL，而子查询可能悄悄走全表扫描还不报错
但别盲目替换：语义和 NULL 处理必须对齐
把 SELECT (SELECT ...) 改成 LEFT JOIN 很稳妥，但把 WHERE ... IN (SELECT ...) 直接套用 LEFT JOIN 就容易出错。
-
NOT IN (subquery)对 NULL 不安全，改 LEFT JOIN 后得补AND right.id IS NOT NULL - 一对多关系（如订单→订单项）直接 JOIN 会膨胀行数，此时用
EXISTS或DISTINCT更合适 - 子查询带
GROUP BY或ORDER BY RAND()→ 物化失效，JOIN 无法等价替代 - 原语句中子查询有
WHERE u.status = 'active'，必须写进ON，写进WHERE就变成 INNER JOIN 语义
真正容易被忽略的是：子查询里一个看似无害的 ORDER BY 或聚合函数，就能让优化器放弃物化；而你还在看执行时间觉得“好像还行”，其实它正以最差方式运行着。
