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

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和UPDATE STATISTICS.两者都在合理的时间内完成

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

我们还应该注意什么？

另请注意,此表之前没有此问题,今天突然出现此问题.我们还有许多具有相同表设置的数据库(客户数据库的副本),并且它们的行为与预期一致,只是这个有问题.