大数据量（>1000行）必须用#temptable，因其支持统计信息、索引和执行计划优化；小数据量（≤100行）优先用@table以避免tempdb开销；函数中禁用#temptable，仅可用@table。
大数据量（>1000行）必须用 #TempTable，否则查询计划会严重失准
SQL Server 查询优化器对 #TempTable 会生成统计信息，而对 @Table 默认不生成——哪怕你插入了上万行。这意味着：当数据量变大后，优化器仍按“空表”或“5行估算”来选执行计划，容易导致嵌套循环误判、索引未走、内存授予不足等问题。
常见错误现象：SELECT * FROM @BigData WHERE Status = 'Active' 耗时突增，但换成 #BigData 后秒出结果；执行计划里出现“Table Scan”而非“Index Seek”，且“Actual Rows”远大于“Estimated Rows”。
- 临时表支持
CREATE INDEX，可加PRIMARY KEY或非聚集索引，这对 JOIN / WHERE / ORDER BY 非常关键 - 若在存储过程中多次重用同一中间结果（如先聚合再筛选再关联），
#TempTable的统计信息能被后续语句复用 - 注意：首次插入后手动执行
UPDATE STATISTICS #TempTable可进一步提升准确性，尤其在批量 INSERT 后立即查询时
小数据量（≤100行）优先用 @Table，避免 tempdb 争用和日志开销
@Table 在内存中初始化，不写入事务日志，也不参与事务回滚——这既是优点也是限制。它适合存配置、参数列表、少量校验结果等轻量场景。
使用场景举例：DECLARE @Config TABLE (Key NVARCHAR(50), Value SQL_VARIANT) 存 5 条开关设置；或 INSERT INTO @Result SELECT TOP 10 ... 做快速截断返回。
- 表变量不支持
ALTER TABLE，不能加新列或索引（主键/唯一约束除外） - 不能在
INSERT ... EXEC中作为目标（INSERT INTO @Table EXEC sp_who会报错） - 嵌套存储过程中无法访问外层声明的
@Table，作用域严格限定在当前批处理（即 BEGIN...END 块内）
别在函数里用 #TempTable，SQL Server 直接拒绝编译
用户定义函数（UDF）禁止创建或引用本地临时表，这是硬性限制。错误信息是：Invalid object name '#MyTemp'. 或更明确的 Cannot use temporary tables in functions.
此时唯一合法替代是 @Table。但要注意：表变量在函数中同样不支持统计信息，且无法显式更新统计（UPDATE STATISTICS 不可用），所以函数内涉及复杂逻辑 + 多次查询时，性能可能不如预期。
- 函数中允许
INSERT INTO @Table SELECT ...，也支持JOIN @Table，但别指望优化器能据此优化连接顺序 - 若逻辑实在绕不开临时表，考虑改用内联表值函数（ITVF）+ CTE，或把该部分移到存储过程中处理
SELECT ... INTO #Temp 比 CREATE TABLE #Temp 更快，但有隐藏风险
SELECT col1, col2 INTO #Temp FROM src 看似简洁，实际会隐式创建表结构并跳过约束检查，还可能因源列为空而让目标列为 NULL，后续 INSERT 易失败。
更麻烦的是：如果该语句在循环中重复执行（比如在 WHILE 里），第二次运行会直接报错 There is already an object named '#Temp' in the database.
- 安全做法始终是显式
IF OBJECT_ID('tempdb..#Temp') IS NOT NULL DROP TABLE #Temp，再CREATE TABLE #Temp (...) - 若确定只执行一次且结构简单，
SELECT ... INTO可省略 DDL，但务必确认源列是否含NULL、精度是否足够（如VARCHAR(MAX)可能被截成VARCHAR(8000)） - 全局临时表（
##Temp）极少需要，多会话并发时易引发命名冲突和清理延迟，不建议主动使用
实际选择不是看“习惯”或“语法顺不顺”，而是盯住执行计划里的 Estimated Rows 和实际物理操作类型。哪怕只有几百行，只要后续要 JOIN 大表或反复过滤，#TempTable 加索引仍是更稳的选择。而 @Table 的“轻量”优势，只在真正轻量时才成立——一旦数据量或操作复杂度越界，它就成了性能黑盒。
