临时表不是问题，滥用才是；应优先用CTE、窗口函数、表变量替代单次使用的临时表，并将事务内非核心逻辑解耦。
能减就减，但别硬减——临时表不是坏东西，滥用才是问题。真正该砍的，是那些本可用一次查询、窗口函数或参数化逻辑替代的中间落盘操作。
用CTE或内联视图替代单次消费的临时表
如果你建 #tmp 就为了在下一句里 JOIN 一次，那基本就是浪费。SQL Server 不会把 CTE 当物理表写入 tempdb，只要没被多次引用，它只是逻辑重写。
- ✅ 适用场景：SELECT * FROM #tmp JOIN orders → 改成
WITH cte AS (SELECT ...) SELECT * FROM cte JOIN orders - ❌ 不适用：同一 CTE 被引用两次（如先聚合再过滤），SQL Server 默认重算两次，反而更慢
- ⚠️ 注意：CTE 里不能有 ORDER BY（除非配 TOP 或 OFFSET），也不能直接 INSERT INTO；想复用多次，得靠物化（SQL Server 2022+ 的
MATERIALIZEDCTE）或改用带索引的#temp
把 GROUP BY / 窗口函数下推到主查询
常见反模式：先塞全量进 #orders_last，再按 user_id 取最新一条。其实 FIRST_VALUE() 或 ROW_NUMBER() OVER (PARTITION BY ...) 一行就能干完，还不占 tempdb。
- ✅ 替换逻辑示例：
SELECT user_id, order_date FROM #last_orders→SELECT user_id, FIRST_VALUE(order_date) OVER (PARTITION BY user_id ORDER BY order_date DESC) AS last_order - ⚠️ 性能陷阱：窗口函数在大数据集上仍可能触发 spill（写 tempdb），但比显式临时表轻量得多；加合适索引（如
(user_id, order_date DESC)）可避免 - ? 检查信号：执行计划里连续出现多个
Table Insert+Clustered Index Scan，大概率是中间表泛滥
用表变量扛住 ≤100 行的中间结果
不是所有中间数据都得落盘。表变量 @config、@ids 这类小数据集，内存优先、不记日志、无统计信息开销，比 #temp 快得多。
- ✅ 合适场景：
DECLARE @config TABLE (key NVARCHAR(50), value SQL_VARIANT)存配置；或INSERT INTO @ids SELECT id FROM t WHERE status = 'pending'（≤100 行） - ❌ 踩坑点：
@t不能在INSERT INTO @t EXEC中作目标；不支持ALTER TABLE；作用域只限当前 BEGIN...END 块 - ⚠️ 关键限制：优化器恒估
@t为 1 行，若后续 JOIN 大表（如百万级 orders），很可能选错 Nested Loop，反而更慢
拆出事务体外的“伪中间逻辑”
最常被忽略的一点：压垮 tempdb 的往往不是临时表本身，而是本该异步跑的日志归档、通知推送、跨库聚合，硬塞进存储过程事务里执行。这些根本不需要中间表，只需要解耦。
- ✅ 正确做法：把“发邮件”“写审计日志”“同步到报表库”等逻辑抽成单独作业或 Service Broker 队列，主流程只管核心数据变更
- ⚠️ 真相：哪怕你把所有
#temp全换成@t，只要还在事务里做跨库 JOIN + INSERT，tempdb 压力照旧——因为 version_store 和锁争用不会消失 - ? 判断依据：查
sys.dm_exec_query_stats的total_logical_writes，如果高频存储过程该项远高于同类，说明中间态写入太重，该拆不该调
临时表不是敌人，不可控的生命周期和错误的数据量预估才是。别光盯着语法替换，先看执行计划里哪一步真在往 tempdb 写，再决定是改写法、加索引，还是直接把逻辑拎出去。
