查询超时 - 零星

Question

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

跟踪代码并找到SQL。通过查询工具运行SQL，它总是在2秒内运行。 sql server的默认超时是10分钟。

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

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

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

由于

Answer 1

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

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

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

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

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

如果通过连接字符串指定了连接超时，则不使用现有的池化SQL Server连接：由于连接池缓存基于所使用的连接字符串，因此会获得新连接。你是否正确处理你的连接/命令/等等？如果您将打开的阅读器留下要读取的数据，则可能会出现导致问题的锁定。有时，SQL Server会窒息，丢弃连接并留下幽灵spid，这也会造成类似的锁争用问题。