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

【问题标题】：DELETE Statement hangs on SQL Server for no apparent reasonDELETE 语句在 SQL Server 上挂起，原因不明
【发布时间】：2010-09-08 12:52:45
【问题描述】：

编辑：已解决，桌子上有一个带循环的触发器（请在下面阅读我自己的答案）。

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

DELETE FROM tablename WHERE pk = 12345

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

我们查看了执行计划，它包含对相关表的许多查找，以确保没有外键会导致删除，但我们已经验证这些其他表中没有任何行引用该特定表行。

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

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

在查询挂起时查看 sp_who 和 sp_lock 的结果，我注意到我的 spid 也有很多 PAG 和 KEY 锁作为偶尔的 TAB 锁定。

该表有1.777.621行，是的，pk是主键，所以是基于索引的单行删除。执行计划中没有表扫描，尽管我注意到它包含一些内容，即 Table Spool (Eager Spool)，但显示的是 Estimated number of rows 1。这实际上是表扫描吗？伪装？它只是说它查看主键列。

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

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

我们还应该看什么？

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

【问题讨论】：

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

好吧，这很尴尬。

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

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

哦，好吧……

感谢所有阅读本文并思考问题的人的眼球。

我会接受 Josef 的回答，因为他是最接近的，并且间接地谈到了级联删除的问题。

【讨论】：