表变量仅适用于≤100行、不参与复杂join或where in的轻量场景；超量使用会导致优化器按1行估算，引发nested loop低效执行、table scan替代index seek等性能问题。
能代替，但必须看数据量和后续操作——≤100 行且不参与复杂 JOIN 或 WHERE IN 的场景才适合用 @table_var 直接替换 #temp；否则容易从“快”变“慢”，甚至查不出结果。
什么时候用 @table_var 真正安全？
表变量不是万能替代品，它只在轻量、单次消费、无统计依赖的场景下表现稳定：
- 存配置项、开关参数（如
DECLARE @Config TABLE (Key NVARCHAR(50), Value SQL_VARIANT)插入 5–10 行） - 做 TOP N 截断（如
INSERT INTO @Result SELECT TOP 20 * FROM orders ORDER BY created DESC） - 作为函数内唯一合法中间容器（函数中禁止
#temp，只能用@table_var） - 嵌套批处理中需隔离作用域（
@table_var不会跨BEGIN...END泄漏，而#temp可能被误引用）
@table_var 在 JOIN 或子查询里为什么常变慢？
SQL Server 默认对表变量按「1 行」估算基数，哪怕你插入了 500 行。优化器看到 SELECT * FROM @BigList b JOIN orders o ON b.order_id = o.id，大概率选 Nested Loop，而不是 Hash Join —— 实际执行时扫描上万行，耗时飙升。
常见错误现象：SELECT * FROM @BigList WHERE status = 'shipped' 执行计划显示「Estimated Rows: 1」，但「Actual Rows: 482」，且走 Table Scan 而非 Index Seek。
规避方法：
- 小数据（≤100 行）+ 简单过滤：可接受
- 中等数据（100–1000 行）+ 需 WHERE / JOIN：改用
#temp并加索引 - 必须用表变量又需准确估算：SQL Server 2022+ 可尝试
OPTION (RECOMPILE)强制重编译，让优化器看到实际行数
哪些操作 @table_var 根本不支持？
别在写之前假设它和普通表一样灵活——硬性限制直接报错：
- 不能用
INSERT INTO @t EXEC sp_who（错误信息：Invalid use of a side-effecting operator 'INSERT EXEC' within a function） - 不能在声明后加索引：
CREATE INDEX IX_id ON @t(id)→ 语法错误 - 不能
ALTER TABLE @t ADD col INT（不支持动态结构变更） - 不能
TRUNCATE TABLE @t（只允许DELETE FROM @t） - 嵌套存储过程中无法访问外层定义的
@t（作用域严格限于当前BEGIN...END块）
真要替换临时表，优先考虑重构而非换语法
把 SELECT * INTO #tmp FROM big_table 换成 DECLARE @t TABLE... 并不能解决性能问题——如果原逻辑本身是「先全量捞出再过滤」，换成表变量只是把 I/O 压力从 tempdb 移到内存，基数误判反而更严重。
真正有效的替代路径是：
- 用 CTE 替代单次中间集（如
WITH cte AS (SELECT ...)后直接 JOIN） - 把 GROUP BY / WINDOW 函数下推到主查询（避免先存聚合结果再关联）
- 高频过程检查
sys.dm_exec_query_stats的total_logical_writes，确认是否真由中间表引起高写入
表变量省的是 tempdb 日志和锁开销，不是执行逻辑的复杂度。数据流没理清，换什么容器都救不了慢查询。
