嵌套子查询更适合一次性过滤、聚合或关联，且结果集不大、不重复执行、不跨会话时使用；临时表则适用于需多次复用中间结果或需索引加速的场景。
什么时候该用嵌套子查询而不是临时表
多数情况下，嵌套子查询比建临时表更轻量、更易维护——只要子查询不重复执行、不跨会话、结果集不大。临时表适合多次复用中间结果或需要索引加速的场景；而嵌套子查询更适合一次性过滤、聚合或关联，尤其在单次查询逻辑清晰时。
常见误用是把本可写成 WHERE 子句里 IN (SELECT ...) 的逻辑硬拆成 CREATE TEMP TABLE + 多次 JOIN，徒增事务开销和清理负担。
- 子查询能被优化器内联（inlined）时，性能未必差，甚至更好
- 临时表强制物化，可能触发磁盘写入（尤其大结果集）
- 嵌套子查询在 PostgreSQL / SQL Server 中支持
LATERAL/APPLY，可实现“每行驱动子查询”，临时表做不到这点
如何写出可读又高效的嵌套子查询
关键不是“能不能嵌套”，而是“嵌在哪”“查什么”。优先把子查询放在 FROM 子句（派生表）或 SELECT 列中（标量子查询），避免滥用 WHERE x IN (SELECT ...) 导致全表扫描。
例如：查每个部门工资最高的员工，用派生表比临时表更直接：
SELECT e.name, e.dept_id, e.salary FROM employees e JOIN ( SELECT dept_id, MAX(salary) AS max_sal FROM employees GROUP BY dept_id ) dept_max ON e.dept_id = dept_max.dept_id AND e.salary = dept_max.max_sal;
-
FROM中的子查询（派生表）会被优化器当作普通表处理，可走索引、可下推条件 -
SELECT中的标量子查询（如(SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id)）必须保证单行单列，否则报错subquery returns more than one row - 避免在
WHERE中对大表用NOT IN (SELECT ...)——空值会导致整个条件恒为 false，改用NOT EXISTS
哪些嵌套子查询容易踩坑
最常出问题的是相关子查询（correlated subquery）没控制好作用域，或者误以为它总能被优化。这类子查询每行执行一次，若外层数据量大，性能会断崖式下跌。
比如这个低效写法：
SELECT u.name, (SELECT AVG(order_amount) FROM orders o WHERE o.user_id = u.id) AS avg_order FROM users u;
- 如果
users有 10 万行，orders有 50 万行，上面语句实际执行约 10 万次子查询 - 加
INDEX(user_id)能缓解，但不如改写成LEFT JOIN + GROUP BY - MySQL 8.0+ 和 PostgreSQL 支持子查询上推（subquery unnesting），但并非总触发，别依赖它自动优化
- SQL Server 对
EXISTS优化较好，但对= (SELECT ...)标量子查询要求子查询绝对单行，否则直接报错
嵌套子查询 vs CTE：什么时候选哪个
CTE（WITH 子句）不是语法糖，它是逻辑命名，不保证物化——多数引擎仍按需计算。所以 CTE 更适合提升可读性或递归查询，而非替代临时表。
真正需要“物化中间结果”时，CTE 并不比临时表可靠。PostgreSQL 的 MATERIALIZED CTE 是例外，但仅限 12+ 版本且显式声明。
- 想复用同一子查询三次？用 CTE 比写三遍嵌套子查询更安全、更易改
- 需要给中间结果加索引或统计信息？只能用临时表
- CTE 中引用自身（递归）时，不能用嵌套子查询替代
- Oracle 的 CTE 默认物化，但其他数据库不保证，别假设行为一致
嵌套子查询的边界很实在：它只是语法结构，不承诺执行计划。真正决定性能的是数据分布、索引、优化器能力，而不是你写了几个括号。
