ton*_*din 4 sql-server sql-server-2005
我们正在开发一个站点，当我们将其部署到客户端的生产服务器时，几个小时后我们开始出现查询超时。
这是由单个用户测试的，在我们的服务器（Sql Server 版本号 - 2005 SP3 相同）上我们从未遇到过同样的问题。
我们的一位高级开发人员在之前的工作中遇到了类似的行为，他运行了一个查询来手动更新统计信息，然后问题神奇地消失了 - 查询在几毫秒内返回。
几个小时后，同样的问题出现了。所以我们再次手动更新统计数据，问题再次消失。我们检查了数据库属性，果然，自动更新统计信息是正确的。
作为临时措施，我们设置了定期更新统计数据的任务，但显然，这不是一个好的解决方案。
以前遇到过这个问题的开发人员确信这是一个环境问题 - 当他以前遇到过这个问题时，几天后它就自行消失了。
我们检查了他们的数据库服务器上的 SQL 服务器安装，这不是我认为正常的情况。尽管他们安装了 SQL 2005（而不是 2008），但安装目录中有一个空的“100”文件夹。还有 MSQL.1、MSQL.2、MSQL.3 和 MSQL.4（这是可执行文件和数据实际存储的位置）。
如果有人有任何想法，我们将非常感激 - 我认为统计数据不是未能更新，而是以某种方式变得腐败。
非常感谢
托尼
不同意莱姆斯的观点……
参数嗅探允许 SQL Server 猜测各种输入值的最佳计划。有时，由于非典型值或默认选择不当，它是错误的并且计划很糟糕。
我曾经能够通过更改 0 和 NULL 之间的默认值来按需演示这一点：计划和性能发生了巨大变化。
统计数据更新将使计划失效。因此，下次使用时将编译并缓存查询
解决方法是以下其中之一：
请参阅这些问题
现在，Remus 在 SQL Server 开发团队工作。然而，微软在自己的网站上详细记录了这种现象，因此指责开发人员是不公平的
| 归档时间： |
|
| 查看次数： |
3629 次 |
| 最近记录： |