2

我对这个存储过程有一个问题，它在整个应用程序中 99% 的时间都在工作，但是当从应用程序的特定部分调用时会超时。

该表只有 3 列，包含大约 300 条记录。存储过程只会带回一条记录，看起来像这样

“从表中选择 * 列 = @参数”

当 sp 在 management studio 中执行时，它需要 :00 秒。

存储过程在我们的应用程序中被大量使用，但似乎只在我们程序的一个特定部分超时。我想不出为什么这么简单的 sp 会超时。有任何想法吗？

这是一个 vb.net 桌面应用程序，使用 sql server 2005。

4

4 回答 4

6

您有一些代码已经在桌子上锁定，因此无法读取。

于 2010-02-10T21:04:03.003 回答
3

尝试

SELECT * FROM Table WITH (NOLOCK) WHERE Column = @parameter
于 2010-02-10T21:08:57.247 回答
1

我们有一个非常相似的问题，我们有几个存储过程会在应用程序中保持超时（约 30 秒），但在 SSMS 中运行良好。

我们使用的短期解决方案是重新运行临时解决问题的存储过程。如果这也为您暂时解决了问题，那么您应该调查参数嗅探问题。

有关更多信息，请参阅http://dannykendrick.blogspot.co.nz/2012/08/sql-parameter-sniffing.html

于 2012-08-13T06:06:02.670 回答
0

您需要获取性能指标。使用 sql profiler 来确认那个时候 SP 很慢或者别的什么。如果当时是 sql 很慢 - 考虑诸如锁之类的东西可能会迫使您的查询等待。让我们知道，届时我们或许可以提供更具体的信息。

如果不是 SP 而是说 VB 代码，像RedGate 的 Ants或JetBrains 的 DotTrace这样的体面配置文件可能会有所帮助。

于 2010-02-10T21:04:27.990 回答