先说一个非常典型的场景：一张包含10万行数据的用户表，每次查询一个用户都要执行一次子查询。结果数据库硬生生把一条SQL拆成了10万次独立的查询。这正是相关子查询严重拖慢大表关联速度的根本原因——外层表的每一行都会触发一次内层查询，10万行就需要执行10万次索引查找。而等价的JOIN写法，通过批量连接、谓词下推和一次扫描，就能够让性能回归正常轨道。不过，改写时需要谨慎处理几个容易踩坑的地方：NULL值的处理、字符集的一致性、索引的匹配度，否则可能越改越慢。

为什么相关子查询在大表上慢得令人难以接受？核心原因就在于“逐行执行”。而JOIN能够让优化器采用批量连接、谓词下推和索引复用，从而避免重复扫描。 ## 相关子查询为什么慢得离谱 当外层表包含10万行数据，且子查询又依赖外层表的字段时，数据库通常只能老老实实地执行10万次内层查询。以这个例子来说明：

SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) FROM user u;

即使`orders.user_id`字段上建有索引，每次仍然需要回表或执行一次索引查找——并不是“扫描一遍数据”，而是“执行10万次索引查找，每次只扫描一小部分数据”。 - 在执行计划中，`select_type`显示为`DEPENDENT SUBQUERY`，这是典型的危险信号。 - 如果外层表没有过滤条件，扫描行数几乎等于全表行数；加上`LIMIT`虽然能够暂时掩盖问题，但本质并未得到改善。 - 某些数据库引擎（例如MySQL 5.7）甚至会为每一次子查询生成临时结构，进一步拖慢整体速度。 ## JOIN 如何做到只扫描一次小表 将子查询改写为等价的`LEFT JOIN`写法后，逻辑就从“对每一行求值”变成了“先关联再聚合”：

SELECT u.name, COUNT(o.id) FROM user u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id;

这时优化器拥有了全局的视角，它可以： - 选择`user`作为驱动表（如果它更小），或者反过来选择`orders`（如果过滤后数据量更小）。 - 将`WHERE`条件（例如`u.status = 1`）下推到驱动表的扫描阶段，提前减少输入的行数。 - 利用`orders.user_id`索引一次性定位所有匹配的记录，而不是反复进行随机的随机寻址（random seek）。 关键点在于：`orders`表只会被顺序扫描（或索引范围扫描）一次，而不是执行10万次随机访问。 ## 改写时最容易踩的坑 并非所有子查询都能直接替换成JOIN，下面几种情况需要特别留意： - `NOT IN`中如果包含`NULL`，语义会完全不同，必须改成`LEFT JOIN ... WHERE o.id IS NULL`，否则结果会出错。 - 标量子查询（例如`SELECT (SELECT name FROM dept WHERE id = u.dept_id)`）改写后需要加上`GROUP BY u.id`或者`DISTINCT`，否则可能会产生重复行。 - 关联字段的字符集不一致（比如`utf8mb4`与`utf8`）会导致JOIN失效，退化成全表比对——这比子查询还要慢。 - 如果没有为JOIN字段建立索引，或者索引顺序与`WHERE`条件及JOIN条件不匹配，优化器依然会选错执行路径。 真正发挥作用的从来不是“使用了JOIN”这个语法，而是“JOIN让优化器获得了足够的信息来做全局决策”。不要只看SQL关键词，而要盯着`EXPLAIN`中的`type`、`key`、`rows`和`Extra`，仔细看清楚到底扫描了多少行、使用了什么索引、是否存在临时表——性能差异最深藏的地方，就在这里。