sql server临时表存在物理开销大、基数估算失准、统计信息缺失致计划僵化、tempdb资源争抢四大问题；应优先用表变量（≤100行）、cte或重构单语句，必要时手动更新统计信息或强制重编译。
临时表每次执行都触发物理创建和销毁
SQL Server 里用 #temp 或 ##temp，不是“声明一下就完事”——每次存储过程运行，SQL Server 都要走完整流程：分配页、写入系统表、生成统计信息（哪怕空表）、插入数据、最后再释放所有资源。这个开销在单次执行里不明显，但一旦进循环或高频调用，I/O 和锁竞争会指数级放大。
常见错误现象：sys.dm_exec_query_stats 中该存储过程的 total_logical_writes 异常高；执行计划里连续出现多个 Table Insert + Clustered Index Scan 节点。
- 避免在 WHILE 循环体里反复
SELECT INTO #t—— 改成先建好表，再用INSERT INTO #t批量追加 - 别用
SELECT * INTO #tmp FROM big_table这种全量塞入方式，WHERE 条件必须提前下推 - 如果只是传参用（比如收集一批
order_id后批量更新），直接用表变量@table_var更轻量
SQL Server 对临时表基数预估严重失准
临时表没有真实统计信息（CREATE STATISTICS 不生效），SQL Server 默认按 1 行估算后续 JOIN 或 WHERE 的输出行数。结果就是：本该走 Hash Join 的地方硬生生用了 Nested Loop，几万行数据嵌套几百万次，执行时间从毫秒级跳到秒级。
使用场景判断：SELECT INTO #t 后立刻 JOIN orders ON #t.id = orders.user_id 是高危模式；而 INSERT INTO @t SELECT ... 后只做简单过滤，风险较低。
- 表变量适合 ≤ 100 行中间集；超 500 行或需多次 JOIN，宁可建带索引的永久表（如
staging_user_batch） - CTE 可替代单次使用的临时表，但同一 CTE 被引用两次 = 重算两次，别在循环里反复定义
- 真要复用中间结果，优先重构为单条语句，比如用
FIRST_VALUE() OVER (PARTITION BY ...)替代先存再关联
统计信息缺失导致执行计划固化失效
临时表创建后，SQL Server 不自动生成统计信息，也不触发查询计划重编译。这意味着：第一次执行时生成的计划，会一直沿用到下次显式清除缓存或重启服务——哪怕你后来往 #t 插了 10 万行，优化器仍按 1 行估算，且不会提醒你。
容易踩的坑：SELECT INTO #t 会触发重编译，但 INSERT INTO #t SELECT 不会；很多人误以为“只要数据变了计划就自动更新”，其实完全不会。
- 若必须用临时表且行数波动大，手动加
UPDATE STATISTICS #t（SQL Server 2016+ 支持） - 对关键存储过程，定期跑
sp_recompile 'YourProcName'强制下次执行重新生成计划 - 监控
sys.dm_exec_cached_plans中对应 plan_handle 的usecounts，长期不变化 + 性能下降 = 计划僵化信号
磁盘 I/O 和内存压力被隐性放大
临时表默认走 tempdb，而 tempdb 是所有会话共享的。频繁创建删除不仅消耗本地内存，还会争抢 tempdb 的 SGAM/PFS 页面、引发闩锁等待（PAGELATCH_UP），尤其当多个存储过程并行执行时，tempdb 成为全局瓶颈。
性能影响比想象中更隐蔽：表面看 CPU 不高、内存充足，但 sys.dm_io_virtual_file_stats 显示 tempdb 文件的 io_stall_read_ms 持续飙升，这就是 I/O 在拖后腿。
- 检查
tempdb文件是否单个数据文件（必须多文件，数量 ≈ CPU 核数，上限 8 个） - 避免在存储过程中用
ORDER BY或DISTINCT触发隐式临时表（即使没显式写#t） - 高频场景下，把临时逻辑提到应用层缓存，或改用内存表（SQL Server 2014+
MEMORY_OPTIMIZED_TABLE_TYPE）
真正卡住性能的，往往不是某一行代码，而是临时表带来的连锁反应：物理开销 + 估算失真 + 计划僵化 + 共享资源争抢。改掉一个 SELECT INTO 可能不够，得顺着执行计划往回推，看哪一步被迫引入了中间表。
