SQL中子查询与JOIN在性能上到底有何区别？-SQL-PHP中文网

dependent subquery是性能杀手，因外层每行都重复执行子查询，如users表10万行则logs扫描10万次；需通过explain关注type和rows，优先优化索引与执行计划。

sql中子查询与join在性能上到底有何区别？

EXPLAIN 里看到 DEPENDENT SUBQUERY 就该警觉

这代表子查询每行都执行一次，是性能杀手。比如 SELECT name FROM users WHERE id = (SELECT user_id FROM logs WHERE user_id = users.id ORDER BY ts DESC LIMIT 1)，users 表有 10 万行，logs 表就得扫描 10 万次——哪怕加了索引，也扛不住。

真正要盯的是执行计划里的 type 和 rows：如果 type 是 ALL 或 index，且 rows 远大于最终结果行数，基本就是相关子查询在反复扫表。

用 EXISTS 替代等值标量子查询，能提前终止；但别写成 SELECT * FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id AND t2.status = 'done') 却忘了给 t2.id 和 t2.status 建复合索引
IN 子查询在 MySQL 5.6+ 多数会被自动转成 semi-join，但前提是子查询里不能有 GROUP BY、ORDER BY 或 LIMIT，否则优化器直接放弃重写
PostgreSQL 对相关子查询的物化支持更激进，但若子查询返回上万行，仍会触发磁盘临时表——看 EXPLAIN ANALYZE 里的 Temp File 记录

JOIN 后 GROUP BY 或 DISTINCT 导致行数爆炸

很多人改写子查询为 JOIN 后反而更慢，问题常出在这儿：SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) FROM users u 改成 SELECT u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id 看似合理，但若一个用户有 500 笔订单，中间结果集就先膨胀 500 倍，再聚合——内存和排序压力陡增。

这时候不如保留子查询，或改用窗口函数：SELECT u.name, COUNT(*) OVER (PARTITION BY u.id)（需 PostgreSQL 11+/MySQL 8.0+）。

LEFT JOIN + COUNT() 必须配 GROUP BY，否则语法错误；而子查询天然隔离计算边界
INNER JOIN 不会放大行数，但会丢掉无订单用户；用 LEFT JOIN 又得防 NULL，COUNT(o.id) 比 COUNT(*) 安全
如果只是判断“有没有订单”，EXISTS 比 LEFT JOIN ... IS NOT NULL 更轻量，不生成中间行

索引失效比写法选择更致命

无论你写子查询还是 JOIN，只要连接字段或 WHERE 条件没走索引，性能差距就毫无意义。比如 WHERE status IN ('active', 'pending')，如果 status 列没索引，IN 子查询和 JOIN 都得全表扫描。

Zcode

Zcode是一款AI开发辅助工具，智谱推出的轻量级AI IDE编程工具。

下载

复合索引顺序决定一切：对 SELECT * FROM orders WHERE user_id = ? AND created_at > ?，索引必须是 (user_id, created_at)，反过来就没用。

子查询中 SELECT id FROM t2 WHERE a = ? AND b = ?，索引 (a, b) 能用，(b, a) 不能用
JOIN 的 ON t1.x = t2.y，两边字段最好都有索引；若只有一边有，驱动表选错会导致嵌套循环变慢
MySQL 8.0+ 的 EXPLAIN FORMAT=TREE 会直接标出“Using index condition”，比老版 Extra 字段更直观