编辑：解决了，有一个触发器，在桌子上有一个循环(在下面进一步阅读我自己的答案)。

我们有一个简单的delete语句，如下所示：

DELETE FROM tablename WHERE pk = 12345

这只是挂起，没有超时，什么都没有。

我们已经研究了执行计划，该计划由对相关表的许多查找组成，以确保没有外键会触发删除操作，但是我们已验证其他表中没有任何行引用该特定行。

目前没有其他用户连接到数据库。

我们已经对其运行DBCC CHECKDB，它报告0错误。

在查询挂起时查看" sp_who"和" sp_lock"的结果，我注意到我的spid具有大量的PAG和KEY锁，以及偶尔的TAB锁。

该表具有1.777.621行，是的，pk是主键，因此它是基于索引的单行删除。执行计划中没有表扫描，尽管我注意到其中包含表缓冲池(Eager Spool)的内容，但表述了估计的行数1. 它只说它查看主键列。

在表上尝试过DBCC DBREINDEX和UPDATE STATISTICS。两者均在合理时间内完成。

不幸的是，此特定表上有很多索引。它是我们系统中的核心表，具有大量的列和引用，包括传出的和传入的。确切的数目是48个索引+主键聚集索引。

我们还要看什么？

还请注意，此表以前没有此问题，今天这个问题突然发生了。我们也有许多具有相同表设置的数据库(客户数据库的副本)，并且它们的行为符合预期，这只是问题所在。

解决方案

回答

尝试在该表上重新创建索引，然后尝试重新生成统计信息。

DBCC索引

更新统计

回答

缺少的一条信息是我们要从中删除数据的表上的索引数。由于SQL Server使用主键作为每个索引中的指针，因此对主索引的任何更改都需要更新每个索引。不过，除非我们谈论的数字很高，否则这不是问题。

根据描述，我猜测这是数据库中的主表，被FK关系中的许多其他表引用。这将解决大量锁问题，因为它会检查表的其余部分以供参考。而且，如果我们已启用级联删除功能，则可能导致表中的删除操作需要对多个表进行深入检查。

回答

好的，这很尴尬。

一位同事不久前向该表添加了一个触发器，并且该触发器有一个错误。尽管他已修复该错误，但从未为该表重新创建触发器。

因此服务器实际上什么也没做，只是做了很多次。

那好吧...

感谢所有阅读并思考问题的人。

我将接受约瑟夫(Josef)的回答，因为他是最接近他的，并且在级联删除操作上间接地解决了这个问题。