表变量能避开重编译，因其声明不产生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，保留计划缓存复用能力
表变量是轻量工具，不是万能解药。数据量、作用域、执行计划依赖度，三者缺一不可——漏掉任何一个，都可能让“降重编译”变成“升延迟”。
