DELETE语句在SQL Server上挂起，原因不明

编辑：解决了，表上有一个带循环的触发器（阅读下面我自己的答案）

---

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

DELETE FROM tablename WHERE pk = 12345

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

我们已经查看了执行计划，它包括对相关表的许多查找，以确保没有外键会在删除时出错，但是我们已经验证了其他表中没有任何一个表有任何引用该特定行的行

此时没有其他用户连接到数据库

我们对它运行了DBCC CHECKDB，它报告了0个错误

当查询挂起时，查看

sp_who

和

sp_lock

的结果，我注意到我的spid有大量PAG和KEY锁，偶尔还有TAB锁

该表有1.777.621行，是的，pk是主键，因此它是基于索引的单行删除。在执行计划中没有表扫描，尽管我注意到它包含一些表示表Spool（Eager Spool）的内容，但表示估计行数1。这真的是伪装的表格扫描吗？它只表示它查看主键列

已尝试DBCC DBREINDEX并更新表上的统计信息。两者均在合理时间内完成

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

我们还应该看什么

---

还请注意，此表以前没有此问题，此问题今天突然出现。我们还有许多具有相同表设置的数据库（客户数据库的副本），它们的行为与预期一样，只是这一个有问题。

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

---

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

---

根据您的描述，我猜这是数据库中的一个主表，被FK关系中的许多其他表引用。这将解释大量锁的原因，因为它检查其余表的引用。而且，如果您启用了级联删除，这可能会导致表a中的删除，需要检查多个表的深度。

好的，这很尴尬

不久前，一个collegue向该表添加了一个触发器，该触发器有一个bug。虽然他已经修复了这个bug，但从未为该表重新创建过触发器

所以服务器实际上什么也没做，只是做了很多次

哦，好吧

感谢所有读过这篇文章并思考过这个问题的人的关注

---

我将接受约瑟夫的回答，因为他的回答是最接近的，并且间接地提到了级联删除的问题。

您确实修复了触发器，不使用循环，不是吗？触发器几乎不应该包含游标或循环。