选子查询还是JOIN取决于数据量、关联逻辑和执行计划。数据量小且逻辑简单时子查询更直观；多表关联、需多字段或去重时JOIN更稳妥；性能需结合EXPLAIN实测，不同数据库版本优化能力差异大。

选子查询还是JOIN，关键看数据量、关联逻辑和执行计划，不是语法习惯问题。

数据量小、逻辑简单时，子查询更直观

比如查“销售额超过公司平均值的员工”，用子查询语义清晰：

SELECT name, salary FROM employees 
WHERE salary > (SELECT AVG(salary) FROM employees);

这种单值比较、无重复计算的场景，子查询可读性强，MySQL或PostgreSQL通常能自动优化成高效执行路径。但注意：子查询若写在WHERE中且含非相关条件（如未关联外层表），数据库一般只执行一次；若为相关子查询（如带WHERE e.dept_id = d.id），可能对主表每行都执行一次，性能会明显下降。

多表关联、需取多字段或去重时，JOIN更稳妥

例如查“每个部门的员工数和平均薪资”，必须联表聚合：

SELECT d.name, COUNT(e.id), AVG(e.salary)
FROM departments d 
LEFT JOIN employees e ON d.id = e.dept_id
GROUP BY d.id, d.name;

这时用子查询强行实现不仅嵌套深、难维护，还容易出错（如漏处理空部门）。JOIN天然支持多字段输出、外连接、索引下推等优化，执行器也更容易生成高效计划。

性能不能只看写法，要看执行计划和索引

• 用EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）看实际是否走索引、是否产生临时表或文件排序
• 子查询若依赖列无索引，可能触发全表扫描；JOIN若ON字段没索引，性能同样崩塌
• 某些场景下，把IN子查询改写为JOIN后，因能利用哈希连接或物化，反而快几倍
• 反之，若子查询结果极小（如WHERE status IN (SELECT id FROM statuses WHERE code = 'active')），且子查询结果被缓存，它可能比JOIN更轻量

别忽略数据库版本和优化器能力

MySQL 8.0+ 对相关子查询做了半连接（semi-join）优化，很多过去慢的IN/EXISTS自动转为JOIN执行；PostgreSQL 12+ 支持子查询内联（subquery flattening），效果类似。所以同一SQL在不同版本表现可能差异很大——不能凭经验一刀切，得结合目标环境实测。