触发统计信息更新的查询优化器似乎正在减慢查询速度。

Question

我们正在运行Server 2016，并且有一个非常简单的存储过程，它使用聚集索引查找表中有1.4亿行的一行进行选择。在该表中，我们保存了最后6个月的数据，每天的行数大致相同。在每天的基础上，我们删除最老的一天，并插入最近的一天。select存储过程的隔离级别设置为读取未提交(据我了解，这有其自身的问题，但我们认为阻塞的风险大于读取不完整数据的风险/可能性)。

最近，select查询的超时时间是30秒(我们设置的超时值--不确定查询实际需要多长时间)。这个问题最终会在30-120秒后自行解决。

我探索了各种可能的原因，但我目前的理论是，查询优化器检测过期统计信息，触发表上的统计数据更新(等待完成)，然后在状态更新后创建执行计划。这是通过查看统计数据上次更新的日期/时间来证实的，这恰好与查询减速相吻合。

边注:第一次出现此问题时，正好与我们每日插入的数据相吻合。第二次发生时，它似乎与插入或删除不一致。但这两次经济放缓都与数据更新相吻合。我不知道为什么这些数据第二次就过时了。

我在这里看到了几个选择：

1. 设置auto stats异步，以便查询优化器不会等待状态更新完成
2. 禁用自动统计更新，并每晚手动更新统计数据(可能还会在存储过程中指定查询提示，以使用聚集索引，但不确定是否有必要)。

那么，我对这一原因的理论听起来合理吗？

我的哪一个选择是最好的？

还有其他选择吗？

Answer 1

所以这并不是说你有一个糟糕的计划，你的问题是你让某人成为自动统计系统的受害者，对吗？

由于您可能知道我们正在讨论的是哪个表(S)，我建议您在表(甚至统计)级别禁用自动更新。您可以使用sp_autostats来完成这个任务。现在，您不影响数据库的其余部分。当然，你自己来处理这些数据的更新。

这假设您得到了好的计划，即使当统计有点不正常。如果不是，那么异步可以是一个选项，但是您将无法控制这个统计数据更新的加载时间。

我不会走暗示路线，除非你发现你的旧统计数据确实有糟糕的计划。因此，把计划的质量看作是另一个方面。当然，它们是相关的，但过时的统计数据并不一定意味着糟糕的计划。

如果这是有用的，您可以捕获时，自动更新统计发生与XE跟踪。或者算一天你有多少。使用事件计数器XE目标。或者捕获实际事件(到一个文件目标)，如果您需要更多的细节，而不是“我在跟踪运行期间总共有这么多”。

例如，对于这样的事情，我有我的"寻找异样“跟踪(只是计算了多少，然后修改跟踪，因为您想要限制事件和/或添加一个文件目标)。