OPTION (RECOMPILE)用于生产？
这个选项似乎得到了很多坏消息。这是应得的吗？
我有一个 DBA，到目前为止，他不喜欢OPTION (RECOMPILE)Report ETL ssis 代理查询这一想法。这些查询（据我所知）按计划的时间间隔按顺序执行。
返回历史：
- SQL 服务器 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-或-sql-server-2012-c247fbb5-4125-dd0f-7789-7b1c126f8241
因此，鉴于上述情况 - 这个选项实际上是否在现实世界中使用？我推荐（并测试）它作为生产环境的一个选项是否可以接受？
我被要求提供更多细节。我提到我确实有其他与该主题相关的帖子。让我提供更多信息：
- 根本问题是来自应用服务器的查询花费的时间超过 60 秒。通常这些查询需要 4 到 10 秒。经过很多痛苦，我确定超时与 ETL 查询一致。15 个查询中有 4 个是具体的。
- 在应用程序服务器中发现了导致问题的因素。具体而言，隔离级别设置为
serializable休眠层内；我了解到，这对于大批量生产环境来说并不是最佳选择。
让我分享其他问题：
OPTION(RECOMPILE)用于真实的文字制作场景。我用它来解决参数嗅探和优化厨房水槽查询。这可能是您问题的答案，但症状表明OPTIMIZE FOR UNKNOWN（与局部变量相同）也可能解决问题。我当然不会因为曾经存在过一个错误而回避一个选项，并且它在几年前就已修复。主要风险
OPTION(RECOMPILE)是使用不当，例如高频查询。是的。OPTION RECOMPILE 适用于查询成本因参数值而显着变化的高成本/低频查询。作为替代方案，请考虑使用Query Store，您可以在其中强制制定一个好的计划。
OPTION (RECOMPILE)正如专家所提到的，生产代码中的查询提示肯定有有效的用例。它通常不是唯一或最好的解决方案，如果使用不当，可能会使您的性能问题变得更糟，尤其是在高频查询时。话虽这么说，但有时在某些情况下，除了查询提示之外没有其他修复方法
OPTION (RECOMPILE)，它是性能问题的解决方案。如果没有更多详细信息，我们不能说您的 SSIS 查询是否是一个示例，但只是我想为您的 DBA 抛出的一般想法，因为就像西斯一样，处理绝对值是不好的。?如果您遇到唯一解决方案是 的情况
OPTION (RECOMPILE)，我会很好奇您的 DBA 对如何解决问题的回应。此外，您应该询问您的 DBA，他对无需测试即可解决此问题有何想法OPTION (RECOMPILE)。因为通常这是一个低风险的测试，如果它对性能的影响比它的帮助更严重，它可以很容易地删除。当没有时间解决根本问题时，我什至发现它对性能绑定很有帮助，因此它在此期间获得了喘息的空间。长话短说，查询提示因风险而臭名昭著，因为人们有错误使用它们的历史。但它们的存在是有原因的，因为它们是正确工作的正确工具。在密切监控时使用的风险很低，在某些情况下
OPTION (RECOMPILE)甚至是唯一的解决方案。如果我可以根据 JD 的评论推荐替代解决方案：
在此站点上发布查询以及执行计划，并询问我们是否有人发现查询有任何明显的问题。显然，假设您的查询不包含任何机密数据。即使 OPTION(RECOMPILE) 会显着帮助查询执行，通过存储过程运行它可能会产生其他效果，而这些效果可能无法通过 Recompile 选项实现。
我已经在生产中看到了很多 OPTION(RECOMPILE) 的用法。
看起来查询计划缓存机制不是很聪明，但它假装聪明所以它喜欢覆盖开发人员对不同上下文中计划可重用性的理解。
一次大的查询重新编译可能需要 20-50 毫秒，而缓存中的错误计划可以将低于 100 毫秒的查询转换为几分钟长的 CPU 占用。在这方面， OPTION(RECOMPILE) 看起来很划算。