估计基数时，优化器如何处理尚未填充的#temp 表？

SQL Server 通常会在存储过程开始执行之前为存储过程中的语句构建一套完整的执行计划。

当存在临时表时，该方法会稍作修改：

• 引用临时表的每个语句的编译都会延迟到该语句实际执行。
• 自 2005 版本以来，SQL Server 就支持语句级重新编译。只有受影响的语句被重新编译；该程序的其余计划不受影响。
• 延迟编译意味着 SQL Server 在优化期间知道临时表的运行时基数。
• SQL Server 还可以自动创建统计信息以支持正在编译的查询。这发生在编译期间，从技术上讲会导致重新编译。
• 因此，构建的执行计划受益于准确的基数信息和自动创建的统计对象（如果启用了该选项）。

从有关重新编译执行计划的文档中：

在 2005 年之前的 SQL Server 版本中，每当批处理中的语句导致重新编译时，整个批处理（无论是通过存储过程、触发器、临时批处理还是预准备语句提交）都会重新编译。从 SQL Server 2005 (9.x) 开始，仅重新编译批处理中触发重新编译的语句。此外，由于 SQL Server 2005 (9.x) 及更高版本具有扩展的功能集，因此还有其他类型的重新编译。

语句级重新编译有利于性能，因为在大多数情况下，少量语句会导致重新编译及其相关的损失，就 CPU 时间和锁而言。因此，对于批处理中不必重新编译的其他语句，可以避免这些惩罚。

并来自表变量延迟编译：

使用表变量延迟编译，引用表变量的语句的编译将延迟到该语句的第一次实际执行。这种延迟编译行为与临时表的行为相同。

这是基本的大纲，但不是全部。

正如在另一个答案中已经指出的那样，存储过程中的临时表也可以被缓存以供重用。这种缓存可以显着提高性能和可伸缩性，但它确实使计划重新编译的条件和统计信息的维护方式变得复杂。

我在Temporary Table Caching Explained和Temporary Table Caching in Stored Procedures 中为感兴趣的（和高级的）读者描述了这些额外的复杂性。

粗略地说，在#temp 表上创建统计信息的基数估计遵循常规非临时表的基数估计。话虽如此，正如Paul White在这里指出的那样，存储过程中的临时表可能会受到缓存统计值的影响。

从上面的页面可以看出：

存储过程中的临时表有许多意想不到的特征：

• 尽管有明确的 CREATE 和 DROP 语句，但临时对象可能会在执行过程中被缓存
• 与缓存的临时对象相关的统计信息也被缓存
• 与临时表的当前内容相比，统计数据可能 100% 错误
• 过程末尾的隐式 TRUNCATE TABLE 会使对列修改计数器的预期影响加倍
• 可以在导致它们被创建的语句之前更新缓存的统计信息
• OPTION (RECOMPILE) 更改在过程调用之间传递列修改的方式
• 手动更新统计不足以强制重新编译

我建议看一下这篇文章，以彻底了解临时表缓存对您的影响。