能，但仅当嵌套子查询被重复引用≥2次，且中间结果集行数可控（通常＜10k行），同时需显式建表、建索引并及时清理。
临时表能真正替代嵌套子查询吗？
能，但仅当嵌套子查询被重复引用 ≥2 次，且中间结果集行数可控（通常
判断依据看 EXPLAIN 或执行计划里的“Repeated”次数和子查询输出行数——不是看语句多深，而是看“算了几遍同样的东西”。
CREATE TEMP TABLE vs. WITH (CTE) 怎么选？
WITH 是逻辑重用，不落盘，无法建索引，适合轻量中间结果（CREATE TEMP TABLE 物理落地，支持 CREATE INDEX、多次 JOIN、甚至 UPDATE，适合重计算、大中间集、多步加工场景。
常见误用：用 WITH 包裹一个耗时 8 秒的聚合，又在后续两个 JOIN 中引用它——数据库很可能重复执行两次。这时必须用临时表。
- PostgreSQL / SQL Server：支持
CREATE TEMP TABLE ... AS SELECT ...一行建表+填充 - MySQL 8.0+：临时表支持索引，但默认引擎是
TempTable，不支持全文/空间索引 - 注意事务作用域：
TEMP表在会话结束或显式DROP前一直存在，跨事务也可见
临时表加索引的关键时机和写法
不加索引的临时表在 JOIN 或 WHERE 过滤时可能全表扫描，性能比原嵌套子查询还差。索引不是“越多越好”，而是匹配后续最重的访问模式。
典型做法：先 CREATE TEMP TABLE，再 INSERT INTO ... SELECT ... 填数据，最后立刻建索引。避免在 AS SELECT 一步里隐式建表——多数数据库不支持同时定义索引。
- 高频
JOIN条件字段（如user_id、order_date）必须建 B-tree 索引 - 若后续有
GROUP BY a, b且频次高，考虑联合索引INDEX(a,b) - SQL Server 注意：临时表名加
#前缀，索引名不能以#开头，否则报错Incorrect syntax near '#'
清理和兼容性避坑点
临时表不自动清理，尤其在连接池复用场景下（如 Node.js pg pool、Java HikariCP），上一个请求建的 #tmp_orders 可能被下一个请求直接复用，导致数据污染或主键冲突。
- 显式加
DROP TABLE IF EXISTS #tmp_orders（SQL Server）或DROP TABLE IF EXISTS tmp_orders（PostgreSQL） - MySQL 不支持
IF EXISTS临时表语法，得先SELECT COUNT(*) FROM information_schema.tables WHERE table_name = 'tmp_orders' AND table_schema = DATABASE()再判断 - 别在存储过程中依赖临时表名全局唯一——不同会话可同时存在同名
#t，但内容隔离；而应用层并发请求若共用连接，就真会撞
最稳的做法：用 NEWID() 或 pg_backend_pid() 动态生成表名，比如 #tmp_orders_123456，哪怕多写两行也比查半天数据错乱强。
