SQL Server-PK delete的性能不佳

我在SQLServer2008R2中有一个表，包含大约400行（几乎没有）-它在主键上有一个聚集索引（这是一个标识）。该表由大约13个其他表通过引用完整性（无级联删除或更新）引用

插入/更新/获取几乎是即时的-我们谈论的是瞬间（正如预期的那样）。但是，使用PK进行删除需要3分钟的时间，而且我从未见过它比1.5分钟快：

DELETE FROM [TABLE] WHERE [TABLE].[PK_WITH_CLUSTERED_INDEX] = 1

该指数严重分散——90%。我重建并重新组织了该索引（以及该表上的其他索引），但我无法将其降低到50%以下

此外，我还将数据库备份/还原到本地PC上，在不到一秒钟的时间内，我没有删除问题。

我没有做的一件事是完全删除聚集索引并重新添加它。这本身就是一个问题，因为SQL Server不允许您在PK索引被其他表引用时删除它

有什么想法吗

更新

---

我应该在我原来的帖子中包含这一点。执行计划将“责任”归咎于聚集索引删除-70%。在引用此表的13个表中，执行计划指出没有一个表超过整个查询的3%——几乎所有的命中索引查找。

如果删除一行，数据库必须检查13个表中没有一个引用该行。在引用要从中删除的表的那些其他表的外键列上是否有足够的索引？

可能该表被生产中另一个耗时的过程锁定。

另一种想法是，该表上是否有删除触发器？这可能是问题的原因吗？

好吧，我有一个答案

首先，我几乎用尽了上面问题中指出的所有选项以及相关的答案。我在一个看似微不足道的问题上运气不佳

我决定做以下几件事：

添加临时唯一索引（so SQL） 服务器将允许我删除 聚集索引）

删除聚集索引

重新添加聚集索引

删除临时唯一索引

---

本质上，我删除并重新添加了聚集索引。我唯一能从中吸取的是，可能部分索引或其物理存储位置已“损坏”（我松散地使用该术语）。

正准备发布同样的内容。一定要看看执行计划，找出是什么造成了瓶颈。好的一点-我应该在我的原始帖子中包含这一点（我会更新它）。这就是说，根据执行计划，70%的操作是在聚集索引删除上进行的。被引用的表几乎都有一个seek，并且没有一个表消耗超过整个查询的3%。@Phile:Jeremiah进行了备份和还原，无法在本地框中重现该问题，这意味着检查引用完整性不会导致问题。是否尝试将索引更改为非聚集索引？@Mark PM-我考虑过这样做。事实上，我在本地PC上做了这项工作，并看到碎片化大大减少了——16%比50%。我不确定可能的副作用。我之所以担心，是因为“主”表（150万条记录）引用了这一点。我可能会遇到什么样的问题？我也考虑过这一点——运行探查器来识别可能的锁，但没有用。目前我还没有发现任何关于锁定的问题。我只是在这一点上感到困惑。这很令人沮丧。这一点很好，但我也已经想到了——没有触发因素。这很好，你可以和我们分享你决定要做的事情。但是你忘了提到结果是什么…@vgv8-没问题，我应该在我的回答中包括这一点。碎片实际上从50%增加到了66%（重建/重组无法再降低），运行查询所需的时间从大约2分钟减少到10秒（仍然太高）。执行计划没有改变。