临时表会导致 SQL Server 重新编译吗？

重新编译存储过程文档说：

每次重新启动 SQL Server 时都会自动重新编译。如果过程引用的基础表经历了物理设计更改，也会发生这种情况。

此外，SQL Server 2012 中的计划缓存和重新编译白皮书指出：

每当批处理引用的任何对象发生架构更改时，都会重新编译该批处理。架构更改定义为以下一项或多项：

• 向表或视图中添加或删除列。
• 在表中添加或删除约束、默认值或规则。
• 向表或索引视图添加索引。
• 删除表或索引视图上定义的索引。这仅适用于相关查询计划使用该索引的情况。
• 删除（注意：不是创建或更新）表上定义的统计信息。这仅适用于查询计划使用该表的情况。更新统计信息（手动和自动更新）可能会导致使用此统计信息的任何查询计划进行与最优性相关的（与数据相关的）重新编译。与最优性相关的重新编译将在后面介绍。

因此，罪魁祸首不是临时表本身，而是对其模式所做的改变。

场景 1（无 #temp 表缓存）

CREATE OR ALTER PROC SomeProc1
AS

CREATE TABLE #my_table(A INT, B INT)

--Recompiled every execution with reason "Deferred Compile"
INSERT #my_table VALUES(1,2);

BeforeSelect1: 

--Recompiled every execution with reason "Deferred Compile"
--and then again with reason "Temp Table Changed" when jumped up to by the GOTO and executed for a second time following index creation
SELECT COUNT(*), A FROM #my_table GROUP BY A;

IF NOT EXISTS(SELECT * FROM tempdb.sys.indexes where object_id = object_id('tempdb..#my_table') and index_id <> 0)
    BEGIN
    CREATE INDEX ix ON #my_table(A);
    GOTO BeforeSelect1
    END


--Recompiled every execution with reason "Deferred Compile"
SELECT COUNT(*), A FROM #my_table GROUP BY A;

按照 SQL Server 2012 中的计划缓存和重新编译白皮书中的描述跟踪编译事件，每次执行都显示完全相同的情况。

在上述情况下，#temp每次执行时，表在执行开始时都不存在。因此，所有引用它的语句都将接受延迟编译，并在首次执行之前立即进行编译。如果您只是线性地流经这些语句，那么这是由于#temp表使用本身而导致的唯一重新编译原因。我在上面添加了一个 GOTO，以使事情变得更有趣，并显示索引创建后第一个 SELECT 语句的第二次重新编译。

场景 2（使用 #temp 表缓存）

CREATE OR ALTER PROC SomeProc2
AS

CREATE TABLE #my_table(A INT  INDEX ix , B INT)

--Recompiled on first execution with reason "Deferred Compile"
INSERT #my_table VALUES(1,2);

--Recompiled on first execution with reason "Deferred Compile"
SELECT COUNT(*), A FROM #my_table GROUP BY A;

--Recompiled on first execution with reason "Deferred Compile"
SELECT COUNT(*), A FROM #my_table GROUP BY A;

与第一个过程相比，显著的变化是没有单独的CREATE INDEX语句。这意味着如果 SQL Server 决定这样做，该#temp表就有资格使用临时表缓存（因为这是本例中唯一的阻塞问题）（在我的开发机器上，这确实需要几次尝试才能看到，因为我的本地 SQL Server 内存有点不足）。当没有重新使用缓存的临时表时，它会显示通常的延迟编译模式。跟踪中粉红色突出显示的区域显示了一次执行，其中它重新使用了缓存的临时表，并且没有重新编译事件。但这并不意味着与表相关的重新编译事件将始终为零#temp。您仍然可以看到常见的其他重新编译原因，例如“统计信息已更改” - 尽管在缓存临时表的情况下这如何工作可能会有问题。