临时表适用于多步骤聚合、反复引用子集、跨批次操作等场景；替代方案优先选cte（单次使用）、派生表或变量表，以降低开销并提升可读性。
临时表适合在复杂查询中暂存中间结果，避免重复计算或简化逻辑，但滥用会导致性能下降和资源占用。关键在于明确使用边界：只在必要时创建，及时清理，并优先考虑更轻量的替代方案。
哪些场景真正需要临时表
当查询涉及多步骤聚合、反复引用同一子集、或需跨多个批次操作数据时，临时表才有价值。
- 嵌套层级深、WITH无法清晰表达的中间结果（如先筛选再分组再关联再过滤）
- 同一数据集被多个后续查询多次JOIN或聚合（比如订单主表+明细表预聚合后供三处业务逻辑复用）
- 需要添加索引、统计信息或执行UPDATE/DELETE等DML操作的中间数据
- 存储过程内需跨多条语句共享的状态集合（如批量处理中的失败ID列表）
比临时表更优的常见替代方案
多数情况下，CTE、派生表或变量表开销更低、可读性更好，也更容易被优化器识别。
- 单次使用的中间结果优先用CTE：语法清晰，不占用tempdb空间，SQL Server和PostgreSQL都支持递归与列别名推导
- 小数据量（：内存为主，无事务日志，但不维护统计信息，不适合复杂JOIN
- 需索引且数据量中等（1万~50万行）可考虑#temp表+显式建索引：例如在插入后立即对关键JOIN字段建非聚集索引
- 纯过滤或重排场景，直接用WHERE/HAVING/ORDER BY + TOP/LIMIT，别提前物化
临时表本身怎么写才高效
临时表不是“一建了之”，结构设计和生命周期管理直接影响性能。
- 显式定义列类型和长度，避免SELECT INTO隐式推断导致精度丢失或过度分配（如用VARCHAR(50)而非MAX）
- 只包含后续真要用到的列，删掉冗余字段——减少I/O和内存压力
- 大数据量插入后，手动更新统计信息（UPDATE STATISTICS #temp）或加OPTION (RECOMPILE)让优化器重估
- 存储过程中务必显式DROP TABLE #temp，尤其在分支逻辑里，防止残留影响下次执行
容易踩坑的典型问题
很多慢查询和阻塞其实源于临时表误用，而不是SQL本身写得差。
- 在循环内反复CREATE/DROP同一临时表：每次DDL都会触发编译锁，改用TRUNCATE + INSERT更轻量
- 把大宽表全量SELECT INTO #temp再WHERE，不如直接在源表加索引或用覆盖索引优化原查询
- 在函数或视图里用临时表：SQL Server不允许，PostgreSQL也不支持，会直接报错
- 忽略tempdb配置：多个并发大临时表可能争用SGAM页，需合理设置文件数量与自动增长策略
