表变量插入快、查询快，临时表插入快但查询慢，普通磁盘表插入慢、查询慢；加唯一索引后插入略慢但查询显著提升。
表变量和临时表在存储过程里到底谁更快
没有绝对“更快”，只有“更合适”。关键看数据量、后续操作类型和是否嵌套调用。SQL Server 2016+ 实测中，@table_var 在插入 #temp 低 15%–30%；但一旦超过 5000 行，尤其带 JOIN 或 WHERE 过滤，#temp 因能建索引、有统计信息，执行计划质量明显更高。
容易踩的坑：
- 误以为表变量“一定在内存”——它实际也走
tempdb，只是不写事务日志；数据量大时照样触发磁盘 I/O - 忽略统计信息缺失：优化器对
@table_var始终按“1 行”估算，导致 JOIN 顺序错误、嵌套循环滥用 - 在存储过程里用
SELECT * INTO #temp后立刻 JOIN，却没加索引，反而比表变量还慢
什么时候必须用临时表，不能用表变量
当你的存储过程需要满足以下任一条件，就绕不开 #temp：
- 要对中间结果建非聚集索引（
@table_var只允许主键/唯一约束附带的系统索引） - 需要
UPDATE/DELETE后再查统计信息（@table_var不维护统计，DBCC SHOW_STATISTICS查不到） - 存储过程嵌套调用：内层过程要访问外层创建的临时表（
@table_var作用域仅限当前批，跨过程不可见） - 动态 SQL 中需引用（
EXEC('SELECT * FROM @t')会报错，而EXEC('SELECT * FROM #t')可行）
典型场景：分页 + 多条件聚合 + 后续多次 JOIN 的报表过程，硬切表变量大概率让执行时间翻倍。
怎样给临时表加索引才不拖慢创建开销
临时表建索引不是“越早越好”，而是“在首次查询前、数据插入完成后”做。否则 SQL Server 可能因未完成插入就尝试优化查询，引发重编译或低效计划。
实操建议：
- 先
CREATE TABLE #t (...)，再INSERT INTO #t ...，最后CREATE INDEX IX_t_col ON #t(col) - 避免在循环里反复建/删临时表；如需多轮处理，考虑用
TRUNCATE TABLE #t清空而非DROP+CREATE - 索引列选高选择性字段，别对
bit或低基数status列建索引——反而增加写开销 - 若只读不更新，可加
WITH (DROP_EXISTING = ON)避免重复创建判断
表变量真能完全替代临时表吗
不能。哪怕数据量很小，以下情况仍推荐临时表：
- 需要
INSERT EXEC（@table_var不支持该语法，SQL Server 报错Incorrect syntax near '@'） - 要
TRUNCATE快速清空（@table_var不支持TRUNCATE，只能DELETE，且无法重置标识列） - 业务逻辑要求事务回滚时中间结果也得消失（
@table_var不受事务影响，ROLLBACK后数据还在） - 调试阶段需查
tempdb.sys.dm_db_session_space_usage监控空间占用——表变量不计入该 DMV
最常被忽略的一点：表变量的“自动清理”看似省事，但正因它不参与事务，当你在 TRY/CATCH 中依赖中间状态做补偿逻辑时，反而更难控制一致性。
