我们应该多久使用一次 Update Statistcs。（更频繁与否）

Question

我们通常使用 Ola Hallengren 的解决方案来处理我们拥有的索引优化作业中的更新统计信息。我们将它安排在所有服务器（1500+）的每个星期日午夜作为标准做法。

现在，有几台服务器在周中出现了很多性能问题，当因性能问题引发事件时，我们为该特定数据库运行 sp_updatestats。我们有一个巨大的环境，其中使用了 2000 到 2016 年的所有版本。在 2012 年和 2014 年的版本中，我们一直在周中手动运行特定数据库的更新统计信息。

最近，由于反复出现的问题，我们还不得不为一些非常活跃的数据库每天安排 sp_updatestats。

我的问题：

1. 我们应该多久安排一次？
2. 过于频繁地安排它有什么缺点？
3. 有没有办法避免定期更新运行如此频繁的缺点，因为我听说编译需要更多时间并且可能会在一段时间内降低性能？

请帮助我了解您在这方面的经验。

Answer 1

我们应该多久安排一次？

您需要自行决定。

• 这将取决于与相关统计数据相关的列的修改（插入更新删除）。您可以使用我的脚本TSQL 查找 SQL Server 统计信息的状态，以查找自上次更新统计信息以来修改的行数。
• 你的自动更新统计开启了吗？
• 由于触发自动更新统计信息时的阈值而导致表的大小。 了解统计信息何时自动更新由 Erin Stellato 详细解释。
• 如果您发现您的自动更新统计数据不够好，您应该考虑手动更新统计数据。
• 如果您有 2014 之前版本的大表，请考虑跟踪标志 2371。请注意，它是 SQL 2016 中的默认值。Erik Darling在 SQL Server 2016 中自动更新统计阈值的更改中谈到了它。

过于频繁地安排它有什么缺点？

Kendra Little 在UPDATE STATISTICS: The Secret IO Explosion 中解释了一些如何更有效地做同样事情的技巧。

有没有办法避免并行运行的定期更新的缺点？

如果您的意思是并行运行更新统计信息，我建议您注意两件事。

1. 不要并行运行同一张表的统计信息，会造成阻塞。自 SQL 2014 以来，这方面有所改进。阅读更多详细信息，请参阅Jonathan Kehayias 的改进对并行统计重建的支持，以及 Microsoft Tiger 团队的 Parikshit Savjani使用 SQL 2014 和 SQL 2016 提高更新统计性能。
2. 更新统计信息的扫描阶段并行进行，并在 SQL 2016 中得到改进。注意并行运行的会话数，您可能会导致其他会话等待可用的调度程序。请参阅相关的问答并行统计更新。

根据您的第 3 个问题的编辑，我建议您阅读Auto Update Stats Async Enabled。

其他资源：

• 何时更新统计信息？
• SQL Server 统计问题我们太害羞了，作者 Grant Fritchey
• sp_updatestatsErin Stellato避免的另一个原因