生产环境中是否使用了 OPTION (RECOMPILE)？

Question

是否OPTION (RECOMPILE)用于生产？

这个选项似乎受到了很多负面报道。值得吗？

我有一个 DBA，到目前为止，他不喜欢OPTION (RECOMPILE)Report ETL ssis 代理查询的核心思想。这些查询（据我所知）按计划的时间间隔按顺序执行。

回溯历史：

• SQL Server 2016
• 通过 ssis 代理运行时导致聚集索引扫描的 ETL 查询。这些查询需要几分钟才能完成并造成严重影响。
• 通过本地存储过程运行的相同查询和参数在不到一秒的时间内执行。

等等，你确定 OPTION (RECOMPILE) 是答案吗？

• 未知。
• 但是在我尝试之前，我需要知道这是否是一个非常糟糕的主意。

我所知道的风险：

• 过去至少有两个与 OPTION (RECOMPILE) 相关的严重错误。同时运行的两个查询可以交换结果集。呃！！ https://support.microsoft.com/en-us/topic/fix-rare-possibility-of-incorrect-results-when-you-use-option-recompile-for-queries-inside-a-procedure-in- sql-server-2014-or-sql-server-2012-c247fbb5-4125-dd0f-7789-7b1c126f8241

因此，鉴于上述情况 - 该选项是否在现实世界中实际使用？我推荐（并测试）它作为生产环境的一个选项是否可以接受？

---

我被要求提供更多细节。我提到我确实有其他与此主题相关的帖子。让我提供更多信息：

• 根本问题是来自应用服务器的查询花费的时间超过 60 秒。通常这些查询需要 4 到 10 秒。经过很多痛苦，我确定超时与 ETL 查询一致。15 个查询中有 4 个是具体的。
• 在应用程序服务器中发现了问题的根源。具体来说，隔离级别设置serializable在休眠层内；我了解到，这对于大批量生产环境来说并不是最佳选择。

让我分享其他问题：

SQL Server - 我可以手术删除一个错误的缓存查询计划还是我追求错误的想法？

为什么通过 SSIS 在 ETL 中查询很慢，但通过本地存储过程查询很快？

Answer 1

OPTION(RECOMPILE)用于实词生产场景。我用它来解决参数嗅探和优化厨房水槽查询。它可能是您问题的答案，但症状表明OPTIMIZE FOR UNKNOWN（与局部变量相同）也可以解决问题。

我当然不会仅仅因为曾经存在一个错误而避免选择一个选项，并且它在几年前就已修复。主要风险OPTION(RECOMPILE)是使用不当，例如高频查询。

Answer 2

是的。OPTION RECOMPILE 适用于查询成本因参数值而显着变化的高成本/低频查询。作为替代方案，请考虑使用Query Store，您可以在其中强制制定一个好的计划。

Answer 3

正如专家所提到的，OPTION (RECOMPILE)生产代码中的查询提示肯定有有效的用例。它通常不是唯一或最好的解决方案，如果使用不当，可能会使您的性能问题变得更糟，尤其是在高频查询中。

话虽如此，相反，有时在某些情况下，除了查询提示之外没有其他修复方法，OPTION (RECOMPILE)并且它是性能问题的解决方案。我们不能说您的 SSIS 查询是否是一个没有更多细节的例子，但只是我想为您的 DBA 抛出的一般想法，因为就像西斯一样，处理绝对值是不好的。

如果您遇到唯一的解决方案是OPTION (RECOMPILE)，我很好奇您的 DBA 对如何解决问题的回应。此外，您应该询问您的 DBA，他对无需测试即可解决此问题的想法是什么OPTION (RECOMPILE)。因为通常它是一个低风险的测试，如果它对性能的影响大于它的帮助，可以很容易地删除它。当没有时间解决根本问题时，我什至发现它对性能绑定很有帮助，因此它在此期间获得了喘息空间。

长话短说，查询提示因有风险而臭名昭著，因为人们错误地使用了它们的历史。但它们存在是有原因的，当它们是正确工作的正确工具时。OPTION (RECOMPILE)在密切监视下使用的风险很低，在某些情况下甚至是唯一的解决方案。