在一个相对较小的SQL数据库上自动更新统计数据和重新制定查询计划是否是一种糟糕的做法？

Question

我有一个大约500 in大小的size数据库。每2-3周，数据库将突然开始缓慢运行，一些查询(由LINQ生成)将超时。执行时间没有逐渐增加，只是突然增加。

修复它的唯一方法是更新统计信息；我通常同时删除查询计划。然后就恢复正常了。

一些索引在开始时用STATISTICS_NORECOMPUTE=ON错误地创建。由于将它们更改为OFF，此问题发生的频率较低。但是，当我查看索引和创建表的SQL时，系统没有什么不寻常的地方，也没有什么不寻常的地方。每天都会添加新行，但没有异常大或小的行。我看到统计数据只更新了表中的20%+500，但是我没有问题地运行其他类似的数据库。

所以，如果我安排每隔几天午夜更新一次统计数据，我是在治疗症状的同时忽略了难以捉摸的原因吗？这是不好的做法还是这是标准的数据库维护？

Answer 1

Server优化器使用统计信息生成执行计划。统计数据越准确，就有可能产生更好的计划。默认情况下，只有当超过20%的记录已被更改时，统计信息才会自动更新。它在实践中意味着什么？假设您有一个包含10个月数据的表，统计数据刚刚重新计算。需要两个月才能再次触发更新统计数据。如果在这段时间内有人运行了一个查询，要求在这两个月的时间内提供一些数据，那么优化者会认为没有匹配条件的记录，并且可能会生成一个非常糟糕的执行计划。

过时的统计数据是性能问题的根源，而不是症状，因此应该定期更新。

重新组织/重新生成不是更新统计数据作业的替代。重新组织根本不更新统计数据。重建并不会更新所有的统计数据。在重建期间只更新索引状态，而不是列状态。

Answer 2

如果自动更新统计数据对DB来说还不够，可以尝试以下几点：

• 手动更新统计信息-推荐Ola Hallengren的脚本，这些脚本可以根据需要配置为维护索引和/或统计信息。测试不同的参数(仅限/索引/采样率等)，并测试每天/每周/在proc启动时或类似的情况下运行，看看什么对您最有效，开销最少。 脚本在这里：https://ola.hallengren.com/ Brent Ozar关于只使用这些脚本更新统计数据的文章：https://www.brentozar.com/archive/2016/04/updating-statistics-ola-hallengrens-scripts/
• 对于大型表启用跟踪标志2371 (如果Server版本早于2016年)，这将降低动态更新统计信息的阈值。该算法自SQL Server 2016以来被用作标准算法。好读物: https://support.microsoft.com/en-gb/help/2754171/controlling-autostat-auto-update-statistics-behavior-in-sql-server https://littlekendra.com/2016/04/18/updating-statistics-in-sql-server-maintenance-answers/#trace-flag-2371