OPTION（RECOMPILE）总是更快；为什么？

Question

我遇到了一种奇怪的情况，将OPTION (RECOMPILE)查询追加到查询中会使查询在半秒内运行，而忽略查询会使查询花费超过五分钟的时间。从Query Analyzer或C＃程序通过执行查询时，就是这种情况SqlCommand.ExecuteReader()。打电话（或不打电话）DBCC FREEPROCCACHE或DBCC dropcleanbuffers没有区别；查询结果总是在OPTION (RECOMPILE)不超过五分钟的情况下即时返回。始终使用相同的参数调用该查询（为了进行此测试）。我正在使用SQL Server 2008。我对编写SQL相当满意，但以前从未OPTION在查询中使用过命令，并且在扫描此论坛上的帖子之前并不熟悉计划缓存的整个概念。我从帖子中了解到，这OPTION (RECOMPILE)是一项昂贵的操作。显然，它为查询创建了新的查找策略。那么，为什么随后的省略的查询OPTION (RECOMPILE)是如此之慢呢？后续查询是否应该利用上一次包含重新编译提示的调用所计算的查找策略？是否有一个查询在每次调用时都需要重新编译提示是非常不寻常的吗？对不起入门级的问题，但我实在无法一马当先。更新：我被要求发布查询...select acctNo,min(date) earliestDate from(     select acctNo,tradeDate as date     from datafeed_trans     where feedid=@feedID and feedDate=@feedDate     union     select acctNo,feedDate as date     from datafeed_money     where feedid=@feedID and feedDate=@feedDate     union     select acctNo,feedDate as date     from datafeed_jnl     where feedid=@feedID and feedDate=@feedDate )t1 group by t1.acctNoOPTION(RECOMPILE)从查询分析器运行测试时，我将在以下几行前添加：declare @feedID intselect @feedID=20declare @feedDate datetimeselect @feedDate='1/2/2009'从我的C＃程序调用它时，参数通过SqlCommand.Parameters属性传递。为了便于讨论，您可以假设参数永远不会改变，因此我们可以排除次佳的参数气味是造成这种情况的原因。

Answer 1

有时候使用OPTION(RECOMPILE)是有意义的。以我的经验，这是唯一可行的选择，是在使用动态SQL时。在探讨这种情况是否对您有意义之前，我建议您重新构建统计信息。这可以通过运行以下命令来完成：

EXEC sp_updatestats

然后重新创建您的执行计划。这将确保在创建执行计划时，它将使用最新信息。

OPTION(RECOMPILE)每次查询执行时，添加都会重建执行计划。我从未听说过将其描述为，creates a new lookup strategy但也许我们只是对同一件事使用不同的术语。

创建存储过程时（我怀疑您是从.NET调用临时sql，但如果使用的是参数化查询，则最终将是存储proc调用）SQL Server尝试确定此查询的最有效执行计划根据数据库中的数据和传入的参数（parameter sniffing），然后缓存此计划。这意味着，如果在数据库中有10条记录的地方创建查询，然后在有100,000,000条记录时执行查询，则缓存的执行计划可能不再是最有效的。

总结-我看不出有什么OPTION(RECOMPILE)好处。我怀疑您只需要更新统计信息和执行计划即可。根据您的情况，重建统计信息可能是DBA工作的重要组成部分。如果您在更新统计信息后仍然遇到问题，建议您发布两个执行计划。

并回答您的问题-是的，我想说，每次执行查询时，最好的选择是重新编译执行计划是非常不寻常的。