我有一个大小约为 500MB 的 SQL Azure 数据库。每隔 2-3 周，数据库就会突然开始运行缓慢，一些查询（由 LINQ 生成）会超时。执行时间没有逐渐增加，只是突然激增。
修复它的唯一方法是更新统计信息；我通常同时删除查询计划。然后恢复正常。
一些索引STATISTICS_NORECOMPUTE=ON在开始时被错误地创建。自从将它们更改为 后OFF，问题发生的频率降低了。但是，当我查看索引和建表 SQL 时，没有任何异常，系统也没有异常。每天都会添加新的行，但不会特别大或特别小。我读到统计信息只更新了表的 20%+500 已更改，但我有其他类似的数据库运行没有问题。
那么，如果我每隔几天安排在午夜更新一次统计数据，我是不是在治标不治本而忽略了难以捉摸的原因？这是不好的做法还是这是标准的数据库维护？
如果自动更新统计信息对您的数据库来说不够用，请尝试以下几种方法：
手动更新统计信息——推荐 Ola Hallengren 的脚本，可以配置为根据需要维护索引和/或统计信息。测试不同的参数（所有/仅索引/采样率等）并测试每天/每周/在进程开始时运行等，看看什么最适合您，开销最少。
脚本在这里：https
: //ola.hallengren.com/ Brent Ozar 关于仅使用这些脚本更新统计数据的文章： https ://www.brentozar.com/archive/2016/04/updating-statistics-ola-hallengrens-scripts /
启用跟踪标志 2371（如果 SQL 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
SQL Server 优化器使用统计信息来生成执行计划。统计数据越准确，它可能生成的计划就越好。默认情况下，仅当超过 20% 的记录已更改时，统计信息才会自动更新。这在实践中意味着什么？假设您有一个包含 10 个月数据的表，并且刚刚重新计算了统计信息。再次触发update statistics需要两个月的时间。如果在此期间有人运行一个查询，要求在这 2 个月内获取一些数据，优化器会认为没有匹配条件的记录，并且可能会生成一个非常糟糕的执行计划。
过时的统计数据是性能问题的根本原因，而不是症状，因此应该定期更新。
重组/重建不能替代更新统计工作。重组根本不更新统计数据。重建不会更新所有统计数据。在重建期间仅更新索引统计信息，而不更新列统计信息。