几个月前，我的 Asp.net 应用程序在对数据库执行简单的选择时给了我一个超时异常，其中包含特定的 where 值。
奇怪的是，如果没有 where 子句（或不同的值），select 会返回没有超时的结果。
通过在所有表中执行“UPDATE STATISTICS WITH FULLSCAN”解决了这个错误。
3个月后，再次出现超时错误，再次通过更新统计信息解决。
这个错误开始频繁发生，然后我开发了一个带有计时器的服务来自动执行更新。
使用更新统计的需要变成每月一次，每周一次，每天一次，每小时一次，现在每 15 分钟一次！
这不正常，对吧？避免此问题的最佳做法是什么？
数据库不小。实际大小几乎是 1 GB（当数据库大约 300 MB 时出现此问题）。
您不必每 15 分钟更新一次统计信息。我的猜测是存在参数嗅探问题。统计信息更新只是强制重新编译并掩盖问题，直到缓存了错误的参数。
做一些关于参数嗅探的功课。查看统计信息更新前后的查询计划。有时，您可以通过向查询添加重新编译提示或更好的索引来解决这些类型的问题。
您是否有在数据库上运行的维护计划？
如果没有，请查看http://ola.hallengren.com/以获得一些很酷的免费代码，用于备份、碎片整理索引和更新统计信息。
您是否为数据库设置了更新统计信息？
http://technet.microsoft.com/en-us/library/bb522682.aspx
数据输入数据库并且统计数据变形是不争的事实。有一个神奇的数字告诉数据库何时自动更新统计信息。它基于输入的行数。在 SQL Server Internals 书籍中搜索答案。
为确保您拥有最新的统计数据，只需运行一项工作来维护它们。
这听起来像是一个非常普遍的问题。正如 rsd808 提到的，这可能是因为 SQL Server 错误地缓存了特定查询的错误计划。CRAFTY DBA 对 Ola Hallengren 维护脚本的推荐也是明智的建议。
如果您包含导致问题的查询的一些详细信息，这将有很大帮助。在我看到这个问题的情况下，它通常与正在使用的非常无害的用户定义函数有关。
如果 UDF 确实是问题所在，原因之一可能是您在两种不同的场景中使用了相同的 UDF。当查询优化器第一次分析查询时，它可能会发现只有几行匹配。这将优化查询，然后从该点开始使用特定计划 -无论其他情况是否可能需要扫描数千行。
如前所述 - 每 15 分钟更新一次统计数据是非常过分的，并且可能会通过要求 SQL 服务器每 15 分钟重新评估每个查询来损害性能，而不是能够存储更长时间的优化计划。
使用www.brentozar.com上提供的优秀资源来帮助分析哪些查询是最受打击的。Brent 有一个 YouTube 频道，其中包含 - 我相信 - 最有价值的在线免费资源，用于对服务器进行性能故障排除和提高查询性能。他在修复慢查询方面的表现甚至使用了 StackOverflow 数据库！