查询计划突然重新编译并降低性能答案

【问题标题】：Query Plan Recompiled suddenly and degrades performance查询计划突然重新编译并降低性能
【发布时间】：2019-07-27 14:38:01
【问题描述】：

场景：我们有一个简单的选择查询

Declare P@

SELECT TOP(1) USERID
FROM table
WHERE non_clusteredindex_column = (@P) ORDER BY PK_column DESC

自 1 年以来，它通常在 0.12 秒内执行。但昨天午夜过后，它突然开始消耗我所有的 CPU 并需要 150 秒才能执行。我检查了 SP_who2 并没有发现死锁，除了这个消耗所有 CPU 的查询之外什么也没有。我决定重新启动服务器以消除任何参数嗅探问题或终止任何陈旧的连接。我在重新启动服务器之前进行了 SLQ 分析器跟踪 1 分钟以进行未来的根本原因分析。重启后，一切恢复正常。我很惊讶并好奇地开始查看我采用的分析器中的执行计划，并与 SAME 查询的当前执行计划进行比较。我发现两者都不一样。

问题之夜前的执行计划与重启后的执行计划相同。（做完美的索引搜索）

但有问题的夜间 SQL 分析器中的执行计划正在执行完整索引扫描，这会占用所有 CPU 并需要 150 秒才能执行。

问题：

我可以说执行计划在昨天午夜之后突然重新编译或查询开始使用新的执行计划（完整扫描），在我重新启动后，它再次开始使用旧的和良好的执行计划（索引搜索）。

第一季度。是什么让 SQL server 突然使用新的 EXECUTION 计划？ 第二季度。是什么让 SQL Server 在重新启动后使用旧的和好的执行计划？ 第三季度。当我传递参数时，任何与参数嗅探相关的东西。但从技术上讲，它不应该是因为参数列组织良好，数据分布均匀。

【问题讨论】：

当查询使用较差的执行计划时，同时加载（插入/更新）大量数据是什么？
另外，还有其他任务正在运行吗？这个时间点听起来很可疑，午夜运行什么家务任务？
没有发生异常加载（插入/删除），当然时间听起来很可疑。但是没有房子保持任务运行。即使我们有任何管家任务，这将如何影响查询以选择新的和错误的执行计划？，我只想知道“SQL 服务器是否有可能重新编译并为相同的旧执行计划使用新的执行计划？突然查询？如果是，为什么？”
是的，它可能会自己重新编译，但会被某些东西触发。出于某些原因，请参阅mssqltips.com/sqlservertip/5308/… 这很可能是参数嗅探问题，可能是由错误或缺失的统计数据引起的，这就是为什么我想知道可能正在进行哪些内务管理任务。服务器重新启动，更新某些查询或刷新计划缓存，诸如此类。
这是否意味着，SQL Restart 将刷新计划缓存？这是否意味着 SQl 服务器需要在每次重启时重新编译所有查询的所有计划？

标签： sql sql-server sql-server-2008 sql-execution-plan query-planner

【解决方案1】：

听起来您遇到了参数嗅探问题。我看不到您的数据，但我们经常发现，即使在简单的查询场景中，当许多行与参数结果匹配并且它翻转到扫描时，即使它不应该或数据存在其他问题，例如许多值是唯一的，但它们在某些情况下决定该列应该在表的大部分中具有 0，从而将所有内容都抛出一个循环。如果来自代码的查询运行缓慢，但您可以从 ssms 执行测试过程，这是一个非常大的危险信号，表明这条线是您的问题。

您是正确的，SQL 重新启动会刷新所有计划缓存，或者您可以手动刷新所有计划，但您绝对不想使用此方法修复单个过程的计划。一个快速的解决方法是您可以执行 EXEC sp_recompile 'dbo.procname';强制它只刷新一个过程执行计划并创建一个新的。重做所有计划，尤其是在繁忙的数据库中，可能会导致其他 proc 严重的性能问题，并且重新启动当然会有一些停机时间。这只是在出现问题时暂时解决问题，但如果您确定了导致问题的参数，我会考虑考虑添加一个优化未知提示，专门为已识别的参数嗅探问题而设计。但也可以确保在您的环境中定期进行一些良好的索引维护，以防导致不良计划而不是 sql 引擎。

【讨论】：

【解决方案2】：

在您的情况下，您可以执行以下操作：

-- 激活数据库设置中的查询存储选项。将操作模式设置为开启。

-- 这将开始为每个请求捕获查询计划。

-- 可以开始跟踪消耗大量资源的查询

-- 最后你可以强制一个执行计划用于这个查询

【讨论】：