SQL中如何引用子查询结果_使用临时表或CTE重构
子查询不能直接多次引用，必须用CTE或临时表包裹
在SQL里，你是不是也遇到过这样的场景：精心写了一个SELECT子查询，结果既想在WHERE条件里用它过滤，又想在SELECT列表里把它作为一列输出？很遗憾，这条路走不通。在大多数主流数据库（比如PostgreSQL、SQL Server、MySQL 8.0+）里，直接这么干要么会报错，要么会导致同一个子查询被重复执行——既拖慢速度，结果也不可靠。问题的根源在于，子查询本身并不是一个被命名的对象，你没办法简单地“给它取个名字然后到处调用”。
那么，正确的解决路径是什么？其实只有两条：要么用WITH子句定义一个公共表表达式（CTE），要么就显式地创建一个TEMPORARY TABLE（临时表）。
什么时候选CTE而不是临时表
CTE，也就是公共表表达式，特别适合那些逻辑分层清晰、且只需要在单个SQL语句内部复用的场景。比如说，你先做一层数据过滤，然后基于这个结果进行聚合，最后再拿聚合结果去关联其他表。CTE的好处是它不落盘、不占索引，生命周期仅限于当前这个查询。
不过，有几点需要特别注意：
- 用
WITH定义的CTE，其作用域仅限于紧随其后的那一条SQL语句。你不能指望在两个独立的SELECT语句之间共享同一个CTE的名字。 - 不同数据库对CTE的实现策略有差异。例如在PostgreSQL中，CTE默认是“物化”的（即先完整计算出来，再供主查询使用），而MySQL 8.0+则默认不物化，这可能导致复杂计算被重复执行。在MySQL里，你可以通过添加
MATERIALIZED提示来强制进行物化。 - 如果CTE产出的结果集很大，并且后续查询需要多次与它进行
JOIN操作，那么由于CTE本身没有索引，性能可能会急剧下降。这时候，临时表往往是更稳妥的选择。
来看一个PostgreSQL的示例：
WITH user_orders AS ( SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE created_at >= '2024-01-01' GROUP BY user_id ) SELECT u.name, o.order_cnt FROM users u JOIN user_orders o ON u.id = o.user_id WHERE o.order_cnt > 5;
临时表更适合跨语句或需索引的场景
当你需要在存储过程或复杂脚本中，反复查询同一个中间结果集时，或者当你明确需要对中间结果建立索引以加速后续的JOIN或WHERE操作时，临时表就是更务实、更强大的工具了。
需要注意的是，不同数据库创建临时表的语法略有不同：
- PostgreSQL: 使用
CREATE TEMP TABLE tmp_user_stats AS ...。表会在会话结束时自动清理。 - SQL Server: 使用
SELECT ... INTO #tmp_user_stats。以#开头的表名代表它是会话级的临时表。 - MySQL: 使用
CREATE TEMPORARY TABLE tmp_user_stats AS ...。该表仅对当前数据库连接可见。
所有类型的临时表都有一个共同点：不支持外键约束，也不能被其他数据库会话访问。
还有一点很容易被忽略：创建完临时表后，如果后续查询要用到它的字段进行关联或筛选，记得立刻为它创建索引。否则，数据库可能会进行低效的全表扫描。就像这样：
CREATE INDEX idx_tmp_user_id ON tmp_user_stats(user_id);
嵌套子查询 vs CTE：性能陷阱常出在哪儿
有些SQL写法，从逻辑上看结果完全等价，但实际执行起来，性能可能相差十倍。这里面有哪些常见的“坑”呢？
- 最典型的莫过于误用了相关子查询。比如写成
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)。这种写法会导致对外层查询的每一行，都重新执行一遍内部的子查询，效率极低。相比之下，先用子查询SELECT DISTINCT user_id FROM orders生成一个独立结果集，再与外层进行JOIN，性能要好得多。 - 在CTE中使用了
ORDER BY或LIMIT，却没有配合OFFSET。在某些数据库引擎中，这可能会阻止一些优化策略的下推，影响性能。 - 在CTE中进行了复杂的计算（例如使用
JSON_EXTRACT或正则表达式匹配），然后在主查询中又多次引用了这个计算字段。需要注意的是，CTE并不会自动缓存表达式的结果，每次引用都可能导致重复计算。
最稳妥的做法是什么？在最终确定写法前，先用EXPLAIN命令查看一下数据库的执行计划。重点关注子查询是否被合理地物化了。如果发现执行计划中存在大量的重复扫描操作，那么就该考虑切换到临时表方案，并为其加上合适的索引。
