必须用#temp而非@table：数据量超1000行、需多次操作、跨批处理调用、需事务一致性；@table仅适用于≤100行单次消费场景，且无统计信息支持。
数据量超过 1000 行、后续要 JOIN 或 WHERE 过滤、需要复用中间结果——必须用 #temp，别碰 @table；否则优化器按 1 行估算，执行计划直接跑偏。
什么时候必须用 #temp 而不是 @table
不是“能用就行”，而是“不用就错”。以下任一条件满足，@table 就不该出现：
-
INSERT INTO @t SELECT ...插入行数 > 1000 —— 优化器仍按 1 行估算，JOIN 时大概率选错嵌套循环（Nested Loop），逻辑读暴增 - 后续语句要对中间集做多次操作：比如先
SELECT过滤，再JOIN主表，再GROUP BY汇总 ——@table不支持非主键索引，WHERE 和 JOIN 性能崩塌 - 存储过程中调用其他存储过程，或执行
EXEC动态 SQL ——@table作用域仅限当前批处理，子过程/动态 SQL 看不到，报错Must declare the table variable "@t" - 需要事务回滚一致性 ——
@table不参与事务，ROLLBACK后它还在，#temp会跟着一起清掉
@table 的安全使用边界
它不是“轻量版临时表”，而是“单次小批量容器”。越界就翻车：
- 只用于 ≤ 100 行的静态配置或参数列表，例如
DECLARE @config TABLE (key NVARCHAR(20), value SQL_VARIANT)存 5 条开关项 - 插入后仅被消费一次，且不涉及
JOIN、WHERE col IN (SELECT ...)或聚合 —— 比如INSERT INTO @ids SELECT id FROM orders WHERE status = 'pending'，紧接着UPDATE order_items SET processed = 1 WHERE order_id IN (SELECT id FROM @ids) - 绝不用于函数内 —— 函数里只能用
@table，但它不支持UPDATE STATISTICS，也没法建非主键索引，大数据量时毫无补救余地
索引和统计信息：#temp 必须提前建，@table 基本没得选
#temp 的优势不在“能存”，而在“能算”。但索引建晚了，等于白建：
- 必须在
INSERT INTO #t之前建索引：CREATE CLUSTERED INDEX IX_id ON #t(id)。如果先插再建，SQL Server 会强制重编译后续所有语句批次，首次执行反而更慢 -
@table只允许在声明时定义主键或唯一约束：DECLARE @t TABLE (id INT PRIMARY KEY, name NVARCHAR(50))；SQL Server 2014+ 支持INDEX关键字建非聚集索引，但没统计信息，优化器依然瞎猜 - 大数据量插入后，手动更新统计信息：
UPDATE STATISTICS #t WITH FULLSCAN——@table完全不支持这条命令
命名、清理和跨会话陷阱
看似细枝末节，实际是线上事故高发区：
-
#t这种短名在并发场景下极易撞车；建议带会话标识：#t_<code>SUBSTRING(NEWID(),1,8)或#t_<code>@@SPID - 别依赖“自动清理”——异常退出时
#temp可能残留；调试阶段务必加DROP TABLE IF EXISTS #t开头 -
##global是危险品：多个会话可见，报表调度或 API 批量调用时，A 写完 B 立刻读到脏数据，甚至主键冲突；除非明确需要跨会话共享，否则禁用 -
@table不用管清理，但作用域极窄：在BEGIN...END块里声明，块外就失效；IF @x > 0 BEGIN DECLARE @t TABLE(...); INSERT... END; SELECT * FROM @t—— 这句SELECT直接报错
真正容易被忽略的是：统计信息缺失不是“慢一点”，而是让优化器彻底失明。哪怕你给 @table 加了主键、用了 OPTION (RECOMPILE)，它也只在重编译那一刻知道行数，后续语句仍按旧估计走。而 #temp 的统计信息是活的，JOIN、WHERE、ORDER BY 全都能感知真实分布——这才是选型的核心分水岭。
