SQL Server - 性能不佳的PK刪除

我有一個SQL Server 2008 R2中包含大約400行（幾乎沒有）的表 - 它在主鍵（這是一個標識）上有一個聚簇索引。該表通過參照完整性（無級聯刪除或更新）由大約13個其他表引用。SQL Server - 性能不佳的PK刪除

插入/更新/獲取幾乎是即時的 - 我們正在談論一瞬間（應該是預期的）。但是，刪除使用PK花費只要3分鐘，我從來沒有見過它快超過1.5分：

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

指數爲大量碎片 - 90％。我重建並重組了該索引（以及該表中的其餘部分），但我無法將其降至50％以下。

此外，我做了數據庫的備份/恢復到我的本地PC，我沒有刪除問題 - 不到一秒鐘。

我沒有做的一件事是完全刪除聚集索引並重新添加它。這本身就是一個問題，因爲SQL Server不允許您在PK索引被其他表引用時放棄它。

任何想法？

更新

我應該在我原來的職位包括在此。執行計劃將「責備」放在聚集索引刪除 - 70％。在引用此表的13個表中，執行計劃表示沒有超過整個查詢的3％ - 幾乎全部遇到索引查找。

2010-10-21 J.C.

我只是在這一點上感到困惑。這非常令人沮喪。 – 2010-10-21 16:13:43

數據文件有多大？ – ulty4life 2010-10-21 17:24:11

它大約是3GB – 2010-10-21 21:01:44

嗯，我有一個答案......

首先，我幾乎用盡上面連同關聯的答案在問題中指出的所有選項。我似乎沒有運氣好像一個微不足道的問題。

我決定做的是以下幾點：

本質上，我抹去了並重新添加了聚集索引。我能夠從中得到的唯一東西就是可能是索引的一部分，或者它被物理存儲的地方是'腐敗'（我使用這個術語是鬆散的）。

2010-10-26 01:55:55

這是很好，你與我們分享你決定做的事情。但你忘了提及什麼結果... – 2010-10-26 04:26:32

@ vgv8 - 不是問題，我應該在我的答案中包含它。碎片實際上從50％增加到66％（重建/重組無法使其降低），運行查詢所花費的時間從大約2分鐘減少到10秒（仍然太高）。執行計劃沒有改變。 – 2010-10-28 16:10:03

如果刪除一行，數據庫必須檢查13個表中沒有引用該行。在那些引用您正從中刪除的表的其他表上的外鍵列上是否有足夠的索引？

2010-10-21 16:06:01

即將發佈相同的東西。絕對要看執行計劃，找出造成瓶頸的原因。 – 2010-10-21 16:07:09

好點 - 我應該在我原來的帖子中包括這個（我會更新它）。這就是說，按照執行計劃，70％的操作是在聚集索引刪除。被引用的表幾乎都有搜索，並且不佔用整個查詢的3％以上。 – 2010-10-21 16:09:56

@Phile：Jeremiah做了備份和恢復，不能在本地複製問題，這意味着檢查參考完整性不會導致問題。 – Codism 2010-10-21 16:12:48

也許表被生產中的另一個耗時過程鎖定。

2010-10-21 16:10:41 Codism

也想過這個 - 跑分析器來識別可能的鎖，但無濟於事。目前我沒有發現任何鎖定。 – 2010-10-21 16:12:51

另一個想法是，桌子上是否有刪除觸發器？它會導致問題嗎？

2010-10-21 16:44:28 HLGEM

好點，但我也曾經想過 - 沒有觸發器。 – 2010-10-21 16:47:16

回答