刪除語句掛在SQL Server沒有明顯的原因

Question

編輯：解決，有一個觸發器與表上的循環（閱讀我自己的答案下面）。

---

我們有一個簡單的DELETE語句看起來像這樣：

DELETE FROM tablename WHERE pk = 12345 

這只是掛起，沒有超時，什麼都沒有。

我們查看了執行計劃，它包含了許多關於相關表的查詢，以確保沒有外鍵可以刪除，但我們已經驗證了其他表中沒有任何行涉及到該行特定行。

此時沒有其他用戶連接到數據庫。

我們已經針對它運行了DBCC CHECKDB，並報告了0個錯誤。

綜觀sp_who並同時查詢掛sp_lock的結果，我發現我的spid有大量的PAG和KEY鎖，以及偶爾的TAB鎖。

該表有1.777.621行，是的，pk是主鍵，所以它是基於索引的單行刪除。執行計劃中沒有表掃描，但我注意到它包含表假脫機（快速假脫機），但是表示估計的行數1.這實際上是否可以是僞裝的表掃描？它只說它看起來在主鍵列。

在表上嘗試了DBCC DBREINDEX和UPDATE STATISTICS。兩者均在合理時間內完成。

不幸的是在這個特定的表上有大量的索引。它是我們系統中的核心表格，具有大量列和引用，既有傳出也有引用。確切的數字是48個索引+主鍵聚集索引。

我們還應該看看什麼？

請注意，此表之前沒有此問題，今天突然出現此問題。我們也有許多具有相同表格設置（客戶數據庫副本）的數據庫，並且它們的行爲與預期相同，只是這是一個有問題的問題。

Answer 1

一個信息缺少的部分是你從刪除的數據表索引的數量。由於SQL Server將主鍵用作每個索引中的指針，因此對主索引的任何更改都需要更新每個索引。雖然，除非我們說的是高數字，否則這不應該成爲一個問題。

我從你的描述中猜測，這是數據庫中的一個主表，由FK關係中的許多其他表引用。這會佔用大量的鎖，因爲它會檢查其餘表以供參考。而且，如果您打開了級聯刪除，則可能會導致表中的刪除操作需要檢查多個表。

Answer 2

嘗試重新創建該表上的索引，然後嘗試重新生成統計信息。

DBCC REINDEX

UPDATE STATISTICS

Answer 3

好吧，這是尷尬。

一位同事前不久添加了一個觸發器，觸發器有一個錯誤。雖然他已經修復了這個錯誤，但該表並未重新創建觸發器。

所以服務器實際上什麼都不做，它只是做了很多次。

哦...

感謝您的眼球大家誰閱讀和思考的問題。

我打算接受約瑟夫的回答，因爲他是最接近的，並間接地在層疊刪除問題上提出了問題。