Sql server 2005 选择/更新会导致sql等待时间过长

我正试图弄清楚这里到底发生了什么。我意识到选择/更新组合可能导致死锁——在这种情况下，需要等待很长时间

情况是这样的 查询是使用三个索引的select语句 非常简单

select * from ProblemTable Where Plan_Id=@planId and 
    Date_entered Between @startDate and @endDate and nabp=@nabp

索引都是非聚集索引：

计划编号 输入日期 计划Id，nabp 都有ProblemTable.Unique\u Id的“输出”

查询B是一个使用两个索引的update语句

索引为：

非聚集日期\输入的ASC、源ASC、DataStartOffset ASC 索引1的索引搜索结果上使用的唯一索引Id上的聚集索引。 更新查询：

Update ProblemTable Set ProcessingTime=@processingTime 
Where dateadd(dd, -datediff(dd, date_entered, 1), 1) = 
dateadd(dd, -datediff(dd, getdate(), 1), 1) 
and DateSource = 'xxyyzz' and DataStartOffset = 93148143

我知道。。dateadd很愚蠢。我没有写这个：

因此，这会扫描一个单独的索引，而不是查询a，但也会使用输入的日期。 由于这种情况，长时间的等待一直在发生。死锁似乎不会发生，但它可能会导致5分钟以上的等待时间，而每个查询通常以秒为单位执行

请注意，插入ProblemTable时也会发生这种情况

所以- 我猜SELECT stmt会锁定它最终根据NC索引搜索确定要选择的行，然后update语句会尝试获取对NC索引搜索返回的行的锁定。但为什么只是花了很长时间，却没有出现僵局

那么问题基本上是:

1为什么等待时间长而不是死锁？ 2.这是什么原因造成的

这里有足够的信息吗

---

编辑1这两个查询都相当快，而且都不会达到这么长的时间。很长时间是“某些”未知锁定问题的结果。没有其他显式事务正在进行。

从单个表中选择通常使用单个索引。如果有多个索引可用，SQL Server将根据自动存储的统计信息，尝试选择最具限制性的索引

等待5分钟的更新不正常。试着找出是什么阻碍了它——这是一个好的开始。我通常怀疑的是一个长期运行的事务，它没有像应该的那样快速提交

You can use Sql Profiler for the root cause of this issue.

您正在为此表使用触发器吗

---

您可以对select语句不使用锁

我也有类似的问题，但它与重新索引表有关，并且我的交换机连接不好。select语句正在阻止它，这就是我试图弄清的“为什么”的细节。Select STMT可以通过单独的更新导致死锁——因此我几乎可以预料到，尽管我认为Select上的索引可以防止死锁，但我们并没有因为这些长时间的等待而出局。没有其他交易，这就是问题所在。我们已经检查了阻塞的进程报告等，并且系统没有使用任何长显式transactions@AdamTuliper：更新会发出意向锁。当意图存在时，新的选择将被阻止，以防止更新被选择无限期延迟。然后，更新将等待所有其他锁完成，然后继续更新行。这在正常情况下是有意义的…但是在这种情况下，select如何长时间阻止此更新？每个查询都在say…中完成。。。。2秒。我们现在看到的等待时间是5分钟。@Adam Tuliper:例如，第一个选择可能会运行5分钟，从而阻塞了意图锁，从而阻塞了所有其他选择。你试过sp_WhoIsActive吗？它可能会立即告诉您发生了什么。我们已经运行了这个-我们还运行了死锁检测器。我想你可能有点忽略了这个问题，但也许不是！第一个select在5分钟内不会运行—我们可以肯定这一点。在这个“问题”期间，等待时间突然增加了100+——如果我们没有特定的索引，而是长时间的等待，我几乎可以预期这里会出现死锁。有些东西导致了长时间的等待，否则不会运行“长”，所以我想知道在锁管理中是否还有我遗漏的东西。阻塞过程就是选择，但是这个选择不会花那么长的时间。这是一个一般性的回答：我们知道工具，我们已经对此做了一些相当高级的分析，并且有关于等待过程和阻塞过程的报告。我们知道是哪两个查询导致了问题。由于许多原因，使用“无锁”可能非常危险——所有这些都可以在许多博客和堆栈溢出问题上找到。重复读取、脏读取、跳过页面等是不使用no lock的几个原因。我们希望了解确切的情况，并有可能修复它，而不是用一个肮脏的读物修补它。