选择/更新导致长sql等待时间

Question

我正在努力了解到底发生了什么。我意识到选择/更新组合会导致死锁 - 在这种情况下是longggg等待。

情景就是这样 查询A是使用三个索引的select语句 （非常简化）

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

索引都是非群集的：

1. plan_id的数据类型
2. Date_Entered
3. Plan_Id，nabp

所有人都有问题表.Unique_Id

的'输出'

查询B是使用两个索引的更新语句

索引是：

1. Non Clustered Date_Entered ASC，Source ASC，DataStartOffset ASC
2. 在索引1的索引搜索结果中使用的Unique_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，但也会使用Date_Entered。 由于这种情况，长时间的等待不断发生。死锁似乎不会发生，但它可能导致5分钟以上的等待时间，其中每个查询通常在几秒钟内执行。

请注意，这也发生在INSTER到ProblemTable

中

所以 - 我猜测SELECT stmt根据NC索引搜索最终确定要选择的行获取锁定，然后更新语句尝试获取对其在NC索引上搜索返回的行的锁定。但是为什么它只是花了很长时间，但没有发生僵局？

问题基本上是：

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

这里有足够的信息吗？

编辑1 这两个查询都相当快，并且都不会接近这么长时间。很长一段时间是由于“某些”未知的锁定问题造成的。没有其他明确的交易正在进行。

Answer 1

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

等待5分钟的更新不正常。试着找出阻碍它的因素 - Adam Machanic's sp_WhoIsActive是一个好的开始。我通常的怀疑是一个长期运行的交易，并没有尽快提交。

Answer 2

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

您是否在使用此表的触发器？

您可以使用无锁作为选择语句