表变量能避开重编译，因其声明不产生ddl事件、不写入系统表；而临时表的create/alter等ddl操作会触发计划失效和重编译。

表变量不会触发存储过程重编译，而临时表在结构变更（如建索引、ALTER）时会强制重编译；但直接用 @t 替换 #t 不等于自动降频——得看数据量、后续操作和作用域是否匹配。

为什么表变量能避开重编译

SQL Server 把临时表的 DDL（CREATE TABLE #t、CREATE INDEX、ALTER TABLE）视为计划失效信号，每次执行都可能引发重编译；表变量声明 DECLARE @t TABLE(...) 属于批处理内变量定义，不产生 DDL 事件，也不写入系统表，因此不会触发重编译。

• INSERT INTO @t SELECT 安全，不重编译
• SELECT * INTO #t FROM ... 每次都重编译（尤其在循环里是高危操作）
• 在同一个存储过程中反复 DROP TABLE #t; CREATE TABLE #t → 必然重编译链
• 表变量无法被 EXEC('...') 或嵌套存储过程访问，这反而是“隔离性优势”，避免跨作用域干扰缓存

哪些场景下用表变量真能降低重编译频率

不是所有 #t 都适合换，只在满足全部条件时才稳：

• 中间结果 ≤ 100 行（例如：配置项、状态码映射、TOP 20 ID 列表）
• 仅单次消费：插入后只用于一次 JOIN 或一次 WHERE col IN (SELECT ... FROM @t)
• 不涉及复杂过滤：WHERE 条件简单（如 status = 'active'），不依赖多列组合统计
• 不在动态 SQL 或 EXEC 中引用（否则报错 Must declare the table variable "@t"）
• 不跨 BEGIN...END 块复用（比如不能在 IF 分支里声明，再在 ELSE 里查）

容易踩的坑：以为换了就安全，其实更慢还卡住

最常见误判是把原用于万级数据的 #t 直接换成 @t，结果优化器按「1 行」估算，导致执行计划崩坏：

• SELECT * FROM @biglist b JOIN orders o ON b.id = o.order_id → 实际 800 行，但执行计划显示 Estimated Rows: 1，强制选 Nested Loop，扫描上万行
• WHERE 条件含 IN (SELECT id FROM @t)，主表百万级时变成隐式循环，比临时表加索引慢 5–10 倍
• 试图在表变量上建索引：CREATE INDEX IX_id ON @t(id) → 语法错误，直接报错
• 想用 INSERT INTO @t EXEC sp_who → 错误信息：Invalid use of a side-effecting operator 'INSERT_EXEC' within a function（即使不在函数里，存储过程中也禁用）

真要降重编译，优先检查这三处

比起盲目替换语法，先确认重编译是否真由临时表引起：

• 查 sys.dm_exec_query_stats，确认 plan_generation_num > 1 且波动与 #t 使用位置强相关
• 把所有 #t 的 CREATE INDEX 移到 INSERT 前，并合并为单次定义（避免 CREATE → INSERT → CREATE INDEX 这种三段式）
• 高频调用过程里，用 OPTION (OPTIMIZE FOR (@param = 'typical_value')) 替代 WITH RECOMPILE，保留计划缓存复用能力

表变量是轻量工具，不是万能解药。数据量、作用域、执行计划依赖度，三者缺一不可——漏掉任何一个，都可能让“降重编译”变成“升延迟”。