临时表本身不是性能问题的根源，真正拖慢存储过程的是它在特定场景下触发的隐式开销和优化器误判；表变量因无统计信息致执行计划错误，万级数据时嵌套循环暴增耗时；索引须建于插入前，结构应显式声明，tempdb配置与业务逻辑拆分才是治本之策。
临时表本身不是性能问题的根源，真正拖慢存储过程的是它在特定场景下触发的隐式开销和优化器误判。
为什么表变量在万级数据时反而更慢
SQL Server 对 @table_variable 完全不收集统计信息，优化器恒定估算为 1 行。一旦实际插入上万行，执行计划就可能选错连接方式——比如该走哈希连接或合并连接，却硬生生用了嵌套循环，导致 CPU 暴涨、逻辑读飙升。
- 典型现象：
SELECT * FROM @t JOIN big_table b ON @t.id = b.id执行时间从 200ms 涨到 8s，执行计划里全是 Nested Loops - 适用边界：≤100 行且只读一次；超过 1000 行必须切回
#temp_table - 函数内强制用表变量——
#temp在 UDF 中直接报错Invalid object name '#MyTemp'
临时表建索引为什么经常白忙一场
索引必须在 INSERT INTO #t 之前创建。如果先插数据再建索引，SQL Server 不仅不会复用已有执行计划，还会强制重编译后续所有语句批次，首次执行反而更慢。
- 错误写法：
INSERT INTO #t SELECT ...; CREATE INDEX IX_id ON #t(id);→ 索引无效 + 首次执行变慢 - 正确顺序：
CREATE TABLE #t (...); CREATE INDEX IX_id ON #t(id); INSERT INTO #t SELECT ...; - 别给
IDENTITY列单独建聚集索引——默认就是聚集的，重复建等于浪费资源 - WHERE 条件含多个字段（如
status = ? AND created_at > ?）→ 建组合索引(status, created_at)，别堆单列索引
触发器或高并发场景下临时表会放大 TempDB 争用
每次触发都新建 #t，意味着频繁抢同一组 GAM/SGAM/PFS 页，PAGELATCH_UP 等待飙升，尤其在短事务高频调用时。
-
SELECT INTO #t被禁用：绕过统计信息更新，且每次分配新空间，无法复用执行计划 - 显式声明结构：
CREATE TABLE #t (id INT, name NVARCHAR(50))，而非依赖SELECT INTO - tempdb 文件数必须匹配 CPU 核心数（如 16 核服务器配 8 个等大文件），否则再怎么调语句也扛不住分配瓶颈
- 真正压垮 tempdb 的往往不是临时表本身，而是本该异步的日志归档、跨库聚合等逻辑被塞进事务里同步执行
最常被忽略的一点：临时表只是症状。你花两小时调索引，不如花十分钟把日志推送拆成消息队列——后者对 tempdb 的减压效果，远超所有 CREATE INDEX 语句加起来。
