我继承了执行以下操作的维护计划：
- 清理旧数据
- 检查数据库完整性
- 执行数据库和事务日志备份
- 重组我们的索引
- 更新统计
- 删除旧的备份和维护计划文件
在 23 分钟的维护计划中，更新统计数据需要惊人的 13 分钟。在这 13 分钟期间，对数据库的访问被阻止（或者至少，从这个数据库到我们其他数据库的复制被暂停）。
我的问题是：
我们什么时候应该更新统计数据，为什么？
这似乎是我们应该比每天少做的事情。我试图让我们摆脱“仅仅因为”做不必要的维护的心态。
AskOverflow.Dev
我继承了执行以下操作的维护计划：
在 23 分钟的维护计划中，更新统计数据需要惊人的 13 分钟。在这 13 分钟期间，对数据库的访问被阻止（或者至少，从这个数据库到我们其他数据库的复制被暂停）。
我的问题是：
我们什么时候应该更新统计数据，为什么？
这似乎是我们应该比每天少做的事情。我试图让我们摆脱“仅仅因为”做不必要的维护的心态。
如果您没有它的维护窗口，那么每天更新统计数据可能有点矫枉过正。 特别是如果您为数据库打开了自动更新统计信息。在您原来的帖子中，您说用户看到此维护计划导致性能下降。是否没有其他时间来运行此维护计划？没有其他窗口？我看到你的计划包括索引重组，你什么时候重建索引？当该操作发生时，统计信息会自动更新（前提是没有为索引关闭）。
您应该多久更新一次统计信息在很大程度上取决于您的索引和数据接收到的数据修改量。如果对数据的修改很少 (
INSERT,UPDATE,DELETE)，那么更新统计作业的计划可能会更不频繁。找出您的统计数据是否过时的一种方法是查看执行计划，如果您估计的行与返回的实际行有很大差异，那么这很好地表明需要提高间隔。在您的情况下，您将走另一条路，可能需要进行一些试验。每周更新统计数据，如果您开始看到陈旧统计数据的迹象，请从那里开始。
如果您对数据库使用自动更新统计信息，请参阅此参考以了解何时更新统计信息的阈值。
何时更新统计数据？
当且仅当自动更新统计功能不足以满足您的要求时。我的意思是，如果自动创建和自动更新统计信息处于打开状态，并且由于统计信息不准确或不最新，您得到了一个错误的查询计划，那么控制统计信息的创建和更新可能是个好主意。但如果您对 sql server 性能和查询执行时间感到满意。
然后我建议停止维护计划中的更新统计命令
updating statistics is important and useful 1. allows the SQL Server query optimizer to produce good query plans consistently, while keeping development and administration costs low 2. Statistics are used by the query optimizer to estimate the selectivity of expressions, and thus the size of intermediate and final query results. 3. Good statistics allow the optimizer to accurately assess the cost of different query plans and then choose a high-quality plan
If you want to do update Statistics manually you should first know When Statistics are updated automatically
如果 SQL Server 查询优化器需要自上次创建或更新统计信息以来已经历大量更新活动的表中的特定列的统计信息，则 SQL Server 通过对列值进行采样（通过使用自动更新统计信息）自动更新统计信息. 统计信息自动更新由查询优化或编译计划的执行触发，它仅涉及查询中引用的列的子集。如果 AUTO_UPDATE_STATISTCS_ASYNC 为 OFF，则在查询编译之前更新统计信息
这里有一些不错的文章，讲述了在 SQL Server 中何时触发更新统计信息
在知道何时触发统计信息后，它将帮助您决定何时手动更新统计信息
要了解有关统计数据及其对性能的影响的更多信息，我在 sqlskills非常好的博客和博主中推荐BrentOzar和Kimberly 。