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