数据库临时表与表变量最核心的存储差异在于：临时表（#Temp）存储在tempdb系统数据库中，其行为更像物理表，会参与事务、产生日志、并支持统计信息；而表变量（@Table）则通常存储在内存（如果内存充足）或tempdb中，不参与事务回滚（除非整个事务失败），不产生统计信息，且在编译阶段就被确定。这直接导致了它们在性能、作用域和适用场景上的根本不同。如果你在存储过程中需要处理大量数据并进行复杂查询，临时表通常是更优选择；如果只是少量数据的中间暂存且不涉及重编译问题，表变量可能更高效。

一、 存储位置与物理结构差异

临时表（以#开头的本地临时表）在创建时，会在tempdb数据库中生成一个实际存在的物理对象。你可以通过系统视图查询其信息，例如在SQL Server中执行：

SELECT * FROM tempdb.sys.objects WHERE name LIKE '#Temp%';

这个表的结构、数据和索引都实实在在地存放在tempdb的数据页和日志页中。这意味着它的存储机制与用户表完全相同，会涉及磁盘I/O、缓存、锁和事务日志记录。

表变量则不同。虽然其声明语法类似变量（DECLARE @t TABLE），但其存储位置并非固定。在理想情况下，当数据量较小时，SQL Server会尝试将其完全保留在内存中。然而，一旦数据量超过阈值（受内存压力影响），或者表变量上创建了索引，它就会被转移到tempdb数据库中存储。但即便如此，它在tempdb中的存在形式也与临时表有微妙差别，通常作为一个特殊的系统对象存在，对用户不完全可见。

二、 事务与日志记录行为对比

这是两者最影响性能的差异点之一。临时表完全参与用户事务。如果你开始一个事务，在临时表上执行插入、更新、删除操作，这些操作都会像在普通表上一样被完整地记录到tempdb的事务日志中。当你回滚事务（ROLLBACK）时，对临时表所做的修改也会被撤销。

BEGIN TRAN;
INSERT INTO #TempTable VALUES (1);
ROLLBACK TRAN; -- #TempTable中的插入操作会被撤销

表变量则具有“微事务”特性。对表变量的修改虽然也会产生日志，但其日志记录方式通常更精简，且最关键的是，它不参与用户定义的事务回滚。上述ROLLBACK语句不会撤销对表变量的插入。表变量的“事务”在其单个语句执行完成后就立即提交。这一特性使得它在频繁插入、删除的场景下可能比临时表更快，因为避免了大量的日志写入和锁开销。

三、 统计信息与查询优化影响

查询优化器依赖统计信息来估算数据分布和行数，从而生成高效的执行计划。临时表支持创建和维护统计信息，无论是自动创建的还是通过CREATE STATISTICS手动创建的。这意味着当临时表中的数据量很大或分布不均匀时，优化器能做出更准确的判断。

表变量则没有统计信息。优化器在编译涉及表变量的查询语句时，对于表变量的行数，它只有一个简单的假设：对于未声明主键或唯一约束的表变量，它假定只有1行；对于声明了主键/唯一约束的，它假定只有1行或一个很小的数字（如100行）。这常常导致严重的性能问题。例如，如果你在一个有10万行数据的表变量上做JOIN，优化器可能会因为它“认为”只有1行数据而选择一个嵌套循环连接，而不是更合适的哈希连接或合并连接，从而产生灾难性的低效计划。

四、 作用域与生命周期管理

本地临时表（#Temp）的作用域限于创建它的连接和当前批处理。它在创建它的会话中全局可见（包括该会话内的所有嵌套存储过程），但当会话断开时会被自动删除。全局临时表（##Temp）对所有连接可见，在创建它的会话断开且所有其他会话的引用释放后删除。

表变量的作用域则像普通变量一样，严格限定于声明它的批处理、存储过程或函数。它在批处理或过程执行结束后立即被释放，生命周期更短，管理更简单，不会因连接池重用而导致残留数据问题。

五、 索引支持的详细区别

临时表支持创建与物理表完全相同的索引类型，包括聚集索引、非聚集索引、列存储索引，并且可以在表创建后通过CREATE INDEX语句添加。这为大数据量的排序、筛选和连接提供了强大的性能优化手段。

CREATE TABLE #Temp (ID INT, Name NVARCHAR(50));
CREATE CLUSTERED INDEX IX_ID ON #Temp(ID);

表变量仅支持在声明时内联定义的索引。你可以在声明时通过PRIMARY KEY或UNIQUE约束隐式创建索引，或在SQL Server 2014及更高版本中，使用INDEX关键字显式定义非聚集索引。但不能在声明后使用CREATE INDEX添加。这限制了其在复杂场景下的后期优化灵活性。

DECLARE @TableVar TABLE (
    ID INT PRIMARY KEY, -- 隐式创建聚集索引
    Name NVARCHAR(50),
    INDEX IX_Name NONCLUSTERED (Name) -- SQL Server 2014+ 显式索引
);

六、 重编译问题的关键考量

临时表可能导致存储过程的重编译。因为临时表在存储过程编译时可能不存在，或者其数据分布（统计信息）在多次执行中发生显著变化，SQL Server可能会在运行时决定重新编译执行计划以获得最优性能。虽然这有时是好事，但过于频繁的重编译会消耗CPU资源。

表变量则不会因其数据变化而导致重编译。由于优化器在编译阶段就对表变量的行数做了固定假设，后续无论表变量中实际插入多少数据，都不会触发基于统计信息变化的重新编译。这带来了执行计划的稳定性，但也带来了前文所述的计划选择可能不准确的风险。这是选择表变量还是临时表时需要权衡的核心矛盾之一。

七、 实际场景选择建议与最佳实践

基于以上差异，在实际开发中应遵循以下原则：

选择临时表（#Temp）的情况：1. 处理的数据量较大（超过数百行）；

2. 查询复杂，涉及多表连接、聚合，且需要准确的统计信息来获得高效执行计划；

3. 需要在不同批处理或嵌套存储过程中重复使用同一数据集；

4. 必须对中间结果创建非内联的复杂索引；

5. 需要显式的事务控制（部分回滚）。

选择表变量（@Table）的情况：1. 处理的数据量很小（通常少于100行）；

2. 仅用于简单的数据暂存和传递，不涉及复杂查询；

3. 需要避免因对象创建和统计信息变化导致的存储过程重编译；

4. 作用域需要严格限制在当前批处理或过程中；

5. 在高并发场景下，希望减少对tempdb的锁争用（表变量锁粒度更小）。

一个进阶策略是混合使用：在存储过程开头，先用表变量快速筛选和存储少量关键数据（如ID列表），然后再将这些数据插入到临时表中，利用临时表的统计信息和完整索引支持进行后续复杂查询。这样可以兼顾前期的速度和后期的优化能力。

八、 总结：从存储本质理解性能表现

归根结底，临时表和表变量的性能差异源于其存储设计的初衷。临时表被设计为临时但“完整”的表，它牺牲了部分轻量性，换来了与物理表一致的功能和优化器支持，适用于重量级的临时数据处理。表变量则被设计为真正的“变量”，追求极致的轻量和作用域可控，但其在查询优化方面的简化假设是主要短板。理解它们各自在tempdb或内存中的存储方式、日志记录机制以及与优化器的交互方式，就能在数据库开发中做出精准的选择，避免性能陷阱，从而编写出高效、可靠的SQL代码。