建议使用STATISTICS_NORECOMPUTE

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

在比较测试和模型环境时，我注意到模型环境中的大多数索引都STATISTICS_NORECOMPUTE设置为，ON而测试中的索引没有设置。在所有环境中，每天都有一项工作来更新所有数据库的统计信息。

我从来没有处理过STATISTICS_NORECOMPUTE，所以这是我的问题。处理此设置时是否有最佳做法？如果我要在一天结束时进行统计信息更新，最好打开STATISTICS_NORECOMPUTE所有环境中的所有索引吗？还是有充分的理由不这样做？

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

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

无论如何，STATISTICS_NORECOMPUTE = OFF出于安全原因，一般建议保留自动更新状态（默认设置）是出于安全原因，因为如果将其关闭并且没有任何手动更新状态，则结果可能是真正可怕的执行计划，永远不会改变首次创建之后（以后不会因为其他原因而使它们失效）。

您说过，大多数索引的自动更新统计信息都处于关闭状态（我想我原本误读为all，而不是大多数）。对于仍启用了自动更新统计信息的索引，鉴于这些表上的活动，此设置有意义吗？我希望这些是活动频繁的表。可能需要做很多工作才能弄清楚这一点，并且值得保留（或强烈考虑）这些设置。至少要记下这些统计信息，因为这些信息可能会派上用场。

再考虑一下，我会说当前的策略确实有意义。这比让所有功能都保持自动更新状态要好吗？似乎有人这样想，以至于值得拥有一个关联的SQL Agent作业来简化管理。

如果这个想法是有提供无阻塞的查询（如新鲜统计本），您可以考虑对所有打开自动更新回去，然后又打开AUTO_UPDATE_STATISTICS_ASYNC为好。然后，您可能希望将工作计划更改为每周运行一次，而不是每天运行一次，因为您仍然希望WITH FULLSCAN定期更新统计信息。

不过，我可能会保留它，因为如果环境之间的索引本身不同，并且统计信息的重建不是很痛苦，则您可能需要炸更大的鱼。现在那里确实有意义。您只需要使环境之间的一致性即可。它可能比我建议的简单设置略胜一筹，但要付出更多工作。但是找出生产中的东西，倾向于使用它，然后转向更重要的事情；当您需要更精细地调整性能时，请重新访问它-世界上最好的统计信息不会保存缺少关键索引的查询。