子查询适用场景包括替代连接、判断存在性或聚合条件：如WHERE salary > (SELECT AVG(salary) FROM emp)、EXISTS检查关联记录、SELECT中生成临时计算列；需规避隐式笛卡尔积、未索引相关子查询、IN含NULL等性能陷阱；优先用JOIN、窗口函数或CTE替代复杂子查询。
SQL子查询不是“嵌套得越深越好”，关键在用对场景、避开陷阱。用得好能简化逻辑，用错了反而拖慢速度、还难维护。
哪些情况适合用子查询
子查询真正有用，是当它能替代连接、或表达“某类数据的存在性/聚合判断”时：
-
筛选满足条件的行：比如“查出销售额高于平均值的员工”，用
WHERE salary > (SELECT AVG(salary) FROM emp)比先算均值再JOIN更直观； -
检查是否存在关联记录：用
EXISTS (SELECT 1 FROM orders WHERE orders.customer_id = customers.id)比LEFT JOIN + IS NOT NULL更高效，尤其外层数据量大时； -
生成临时计算列：比如每条订单旁显示该客户历史总消费，可写成
(SELECT SUM(amount) FROM orders o2 WHERE o2.cust_id = o1.cust_id)——适合结果集不大、且不需多次复用该值的场景。
这些写法要小心（性能雷区）
子查询容易写出“隐式笛卡尔积”或“反复执行”，导致慢得离谱：
-
相关子查询没走索引：如果子查询里用到外层字段但对应列没索引，数据库可能对每一行都全表扫描内层表；确认
EXPLAIN里type是否为ref或range，别是ALL； -
SELECT 中放子查询又没限制返回行数：比如
(SELECT name FROM users WHERE id = order.user_id)看似安全，但如果users表有重复id（没主键/唯一约束），就可能报错或返回多行；加LIMIT 1或确保关联字段有唯一性约束； -
用IN + 子查询含NULL：若
SELECT * FROM t1 WHERE col IN (SELECT col2 FROM t2)中t2.col2有NULL，整个IN判断会变NULL，结果为空——改用EXISTS或提前过滤NULL。
能不用子查询时，优先考虑什么
不是所有嵌套逻辑都该用子查询。多数时候，JOIN、窗口函数或CTE更清晰、更快：
- 需要多个字段或做多表关联，直接JOIN比多个子查询拼字段更易读、优化器也更好处理；
- 要算“每个部门最高薪”，用
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)比子查询找MAX再匹配更稳定； - 子查询逻辑复杂、被多次引用，提成CTE（
WITH tmp AS (...) SELECT ... FROM tmp）既提升可读性，也让优化器有机会复用中间结果。
基本上就这些。子查询是工具，不是目标。想清楚“我要表达什么逻辑”，再选最直白、数据库最容易优化的方式。
