使用 STATISTICS_NORECOMPUTE 的可取性

Question

我最近参与维护一组具有一些有趣索引问题的数据库。最让我恼火的是开发、测试、模型和生产机器之间的指标差异。由于差异使得调优查询变得相当困难，因此同步它们是我的第一个项目之一。

当我比较了测试和模型环境时，我注意到模型环境中的大多数索引都STATISTICS_NORECOMPUTE设置为 ，ON而测试中的索引没有。在所有环境中，都有更新所有数据库统计信息的夜间作业。

我以前从未处理过STATISTICS_NORECOMPUTE，所以这里是我的问题。处理此设置时是否有任何最佳做法？如果我在一天结束时进行统计更新，最好打开STATISTICS_NORECOMPUTE所有索引的所有环境？或者有充分的理由不这样做吗？

编辑：我发现了金佰利特里普的关于这一主题的博客之一在这里，似乎表明STATISTICS_NORECOMPUTE应谨慎充其量只能使用。但我仍然担心在全球范围内关闭它。有没有人试过这个，他们经历了什么？

Answer 1

您想要查看每个表或每个索引的情况确实是一种情况，并且您确实需要在采取任何行动之前找出生产中的内容。如有疑问，也可以在其他环境中使用生产中的内容，即使这意味着使用一堆疯狂的设置。如果测试或开发中的情况不同，您就无法很好地了解生产的行为方式。

无论如何，STATISTICS_NORECOMPUTE = OFF出于安全原因，一般建议启用自动更新统计信息（默认值），因为如果将其关闭并且没有手动更新统计信息，结果可能是永远不会改变的非常可怕的执行计划在它们第一次创建之后（并且以后不会因为其他原因而失效）。

您说大多数索引的自动更新统计信息已关闭（我想我最初误读了all，而不是most）。对于仍启用自动更新统计信息的索引，考虑到这些表上的活动，此设置是否有意义？我希望这些是活动度较高的表。可能需要进行大量工作来解决这个问题，并且可能值得保留（或强烈考虑）这些设置。至少，记下这些统计数据，因为这些信息可能会派上用场。

想多了，我会说目前的策略确实有道理。是否比为所有内容保留自动更新统计信息更好？似乎有人这么认为，以至于拥有相关的 SQL 代理作业的易于管理权衡是值得的。

如果想法是在不阻塞查询的情况下提供新的统计数据（像这样），您可以考虑重新打开所有内容的自动更新，然后也打开AUTO_UPDATE_STATISTICS_ASYNC。然后可能将作业计划更改为每周运行一次而不是每天运行一次，因为您仍然希望WITH FULLSCAN定期更新统计信息。

不过，我可能会离开它，因为如果环境之间的索引本身不同，那么您可能有更大的鱼要煎，而且统计信息重建不会太痛苦。现在有什么是有道理的；你只需要让不同环境的东西保持一致。它可能比我建议的更简单的设置稍微好一点，但代价是要做更多的工作。但是找出生产中的东西，倾向于使用它，然后转向更重要的事情；当您需要更精细地调整性能时，请重新审视这一点——世界上最好的统计数据不会保存缺少关键索引的查询。