查询超时 - 零星

Question

让ASP.net Web应用程序查询来自SQL Server 2005数据库的数据。有一个页面会偶尔超时。

追溯代码并找到SQL。通过查询工具运行SQL，它总是在2秒内运行。 SQL Server的默认超时时间是10分钟。

此问题的解决方法是将sql server超时更改为20分钟，然后再更改为10分钟。然后页面通常需要2秒钟来查询和显示。

看过可能的锁定，但没有显示会导致问题。关于唯一的结论是重置超时设置正在杀死一个进程。

寻找一些可以追踪的想法。

谢谢

Answer 1

有两种不同的超时在这里玩。连接超时（在连接字符串中指定，并作为SqlConnection的属性）和查询超时（属性SqlCommand.CommandTimeout）。默认值为：

• 连接超时：15秒。
• 查询超时：30秒。

查询超时被定义为“所有网络的累积超时的结果的命令执行或处理过程中进行读取。在返回的第一行后仍可以发生超时，并且不包括用户处理时间，只有网络读取时间“

网络读取时间消耗（包括网络争用）的很多原因。我会寻找的东西：

• 阻塞在SQL Server中。
• 统计数据过期。
• 执行计划。你在查询分析器中获得了很好的执行计划吗？
• 陈旧/欠佳的执行计划缓存。如果问题查询是参数化存储过程或查询，则缓存的执行计划是在首次执行查询时获取的。它基于第一次调用的参数值。如果为该调用提供的参数是异常值/非正常值，则对于大多数执行，缓存的执行计划可能不是最理想的。
• 存储过程重新编译。一个交织SQL/DML和DDL的存储过程（例如，将SELECT语句与创建临时表交错）将导致每次创建临时表时都会重新编译。编译锁可以防止相同存储过程的其他执行者继续执行，直到执行计划重新编译完成。如果您使用临时表，应在执行任何DML CRUD之前先声明它们。

如果您通过连接字符串指定了连接超时，则不会使用现有的连接SQL Server连接：由于连接池高速缓存基于所使用的连接字符串，因此会获得全新连接。你正确地Dispose（）'你的连接/命令/等？如果你留下一个阅读数据的开放阅读器，你可能会留下一个锁，导致问题。有时，SQL Server扼流器会丢弃连接并留下一个鬼spid，这也会引起类似的锁争用问题。