看起来您的查询花费的时间比应该花的时间更长。从堆栈跟踪和代码中，您应该能够确定确切的查询内容。
这种类型的超时可能有三个原因：
- 某个地方有僵局
- 数据库的统计信息和/或查询计划缓存不正确
- 查询太复杂，需要调整
死锁可能很难修复，但是很容易确定是否是这种情况。使用Sql Server Management
Studio连接到数据库。在左窗格中，右键单击服务器节点，然后选择“ 活动监视器”
。看一下正在运行的进程。通常，大多数将处于空闲或运行状态。发生问题时，您可以通过进程状态识别任何阻塞的进程。如果右键单击流程并选择 详细信息，
它将向您显示该流程执行的最后一个查询。
第二个问题将导致数据库使用次优查询计划。可以通过清除统计信息来解决：
exec sp_updatestats
如果这样不起作用，您也可以尝试
dbcc freeproccache
当服务器负载沉重时，您不应该这样做，因为它将在首次执行时重新编译所有存储的proc和查询，从而暂时造成巨大的性能损失。但是，由于您指出该问题 有时会
发生，并且堆栈跟踪指示您的应用程序正在启动，因此我认为您正在运行的查询仅偶尔运行一次。通过强制SQL
Server不要重用以前的查询计划，可能会更好。有关如何执行此操作的详细信息，请参见此答案。
我已经谈到了第三个问题，但是您可以通过手动执行查询（例如使用Sql Server Management
Studio）来轻松确定查询是否需要调整。如果查询花费的时间太长，即使重置统计信息后，您可能仍需要对其进行调整。为了获得帮助，您应该在新问题中发布确切的查询。
