SQL子查询改写为JOIN为何能提升大表关联速度

先说个常见场景：一张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`索引一次性定位所有匹配记录，而不是反复进行随机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` vs `utf8`）会导致JOIN失效，退化成全表比对——比子查询还要慢。 - 没给JOIN字段建索引，或者索引顺序不匹配`WHERE`和JOIN条件，优化器照样会选错执行路径。 真正起作用的从来不是“用了JOIN”这个语法，而是“JOIN让优化器获得了足够信息来做全局决策”。别只改SQL关键词，盯着`EXPLAIN`里的`type`、`key`、`rows`和`Extra`，看清楚到底扫了几行、用了什么索引、有没有临时表——性能差异藏得最深的地方，就在这里。