编辑:解决了， table 上有一个带圈的触发器(在下面进一步阅读我自己的答案)。
我们有一个简单的delete语句，如下所示:
DELETE FROM tablename WHERE pk = 12345
这只是挂起，没有超时，什么都没有。
我们已经研究了执行计划，该计划由对相关表的许多查找组成，以确保没有外键会触发删除操作，但是我们已验证其他表中没有任何行引用该特定行。
目前没有其他用户连接到数据库。
我们已经对其运行DBCC CHECKDB，它报告0错误。
在查询挂起时查看
sp_who和sp_lock的结果，我注意到我的spid有很多PAG和KEY锁，以及偶尔的TAB锁。该表具有1.777.621行，是的，pk是主键，因此它是基于索引的单行删除。在执行计划中没有表扫描，尽管我注意到其中包含表假脱机(急切假脱机)的内容，但表示估计的行数1。这实际上可能是变相的表扫描吗？它只说它查看主键列。
在表上尝试过DBCC DBREINDEX和UPDATE STATISTICS。两者均在合理时间内完成。
不幸的是，此特定表上有大量索引。它是我们系统中的核心表，具有大量的列和引用，包括传出的和传入的。确切的数目是48个索引+主键聚集索引。
我们还要看什么？
还请注意，此表以前没有此问题，今天这个问题突然发生了。我们也有许多具有相同表设置的数据库(客户数据库的副本)，并且它们的行为符合预期，这只是问题所在。
最佳答案
缺少的一条信息是您要从中删除数据的表上的索引数。由于SQL Server使用主键作为每个索引中的指针，因此对主索引的任何更改都需要更新每个索引。不过，除非我们谈论的数字很高，否则这不是问题。
根据您的描述，我猜测这是数据库中的主表，被FK关系中的许多其他表引用。这将解决大量锁问题，因为它会检查表的其余部分以供引用。而且，如果您启用了级联删除功能，则可能导致表中的删除操作需要对多个表进行深入检查。
关于sql - DELETE语句无明显原因卡在SQL Server上，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56070/