不能，也不该强求替代；子查询适合“基于结果的条件判断”，如查销售额超平均值的员工，join擅长“关系展开”，如拼接订单与用户表生成带姓名的订单列表，强行替代会导致可读性差、性能差甚至逻辑错误。
子查询能完全替代 JOIN 吗？
不能，也不该强求替代。子查询和 JOIN 解决的是不同层次的问题：子查询适合表达「基于结果的条件判断」，比如“查出销售额超过平均值的员工”；而 JOIN 更擅长「关系展开」，比如“把订单表和用户表拼成一份带姓名的订单列表”。强行用子查询改写多表关联，往往导致可读性暴跌、性能失控，甚至逻辑错误。
WHERE 中的标量子查询：安全又常用
这是最稳妥的子查询替代场景——当只需要从另一张表取一个值做过滤或计算时，标量子查询（返回单行单列）比 JOIN 更清晰。例如统计每个部门高于本部门平均薪资的员工：
SELECT name, salary, dept_id FROM employee e1 WHERE salary > ( SELECT AVG(salary) FROM employee e2 WHERE e2.dept_id = e1.dept_id );
注意点：
- 子查询必须加别名（如
e2），否则无法关联外层e1.dept_id - 如果子查询可能返回空（如某部门无人），
AVG()返回NULL，整个比较结果为UNKNOWN，该行被过滤——这符合三值逻辑，但容易被忽略 - 数据库通常能对这类相关子查询做优化（如物化），但 MySQL 5.7 以前版本可能重复执行，需留意执行计划中的
DEPENDENT SUBQUERY
IN 和 EXISTS 的选择：不只是语法差异
查“哪些用户下过订单”，用 IN 还是 EXISTS？关键看 NULL 和性能：
-
IN子查询若返回NULL（如SELECT order_user_id FROM orders WHERE status IS NULL），整条IN判断结果为UNKNOWN，匹配失败——哪怕有非空值也无效 -
EXISTS不受NULL影响，只关心是否存在行，语义更可靠：SELECT id, name FROM user WHERE EXISTS ( SELECT 1 FROM orders WHERE orders.user_id = user.id );
- 多数情况下
EXISTS比IN快，尤其子查询表大、外层表小时，因为它是“找到一行就停”，而IN常需收齐全部结果再哈希匹配
用子查询替代多层 JOIN 的陷阱
试图用嵌套子查询代替 JOIN ... JOIN ... 来“避免连接”，实际会放大问题：
- 每层子查询都可能重复扫描同一张表，
JOIN却能一次扫描+哈希/合并——在 PostgreSQL 或 SQL Server 上，嵌套子查询的执行计划常出现多次Seq Scan，而等价JOIN是单次扫描+Hash Join - 无法利用复合索引的覆盖特性：子查询里
SELECT id再在外层JOIN，不如直接JOIN并SELECT所需字段高效 - 写法迅速失控：三层
JOIN改成子查询后，缩进深、别名乱、调试困难，比如(SELECT ... (SELECT ... (SELECT ...)))很难定位哪一层漏了WHERE条件
真正需要警惕的，不是“能不能写”，而是“为什么非得绕开 JOIN”——很多时候，问题根源在数据模型冗余、缺失索引，或没理解 JOIN 的驱动表选择机制。
