MS SQL最佳執行計劃編譯中止到期超時

Question

我有兩個表（表1，表2）和表1中的Id是表2中的外鍵。兩個表都有刪除更新其他表的觸發器（表3）。在表2上刪除Table1級聯刪除。當我在表2觸發

SQL Server parse and compile time: 
    CPU time = 391 ms, elapsed time = 10726 ms. 

StatementOptmEarlyAbortReason="TimeOut" 

執行

delete from Table1 
where Table4Id = @table4Id 

我'讓編纂超時在刪除觸發器表1從

UPDATE table3 
SET table3.Column1 = NULL 
FROM Table3 AS table3 
    JOIN DELETED AS deleted ON deleted.Table4Id = table3.Table4Id 
WHERE deleted.Column1 = 1 

上的Delete鍵觸發從表2可以

UPDATE table3 
SET table3.Column1 = NULL 
FROM Table1 AS table1 
    JOIN DELETED AS deleted on deleted.Table1Id = table1.Id 
    JOIN Table3 AS table3 ON deleted.Table3Id = table3.Id 
WHERE table1.Column1 = 1 AND table1.Table4Id = table3.Table4Id 

有沒有辦法擺脫這種編譯超時？

Answer 1

有沒有辦法擺脫這種編譯超時？

這不是一個問題，這已被本傑明Nevarej說明如下：The Phases of Query Optimization

查詢優化器是基於成本的優化，當我們提出一個查詢時，它可以根據查詢的複雜經歷不同的階段。那些相是

相位0 - 事務處理
第1階段--quick計劃
第2階段 - 全優化

，並且還多一個相稱爲超時，下面是超時階段

的解釋的DMV還可以顯示一個超時事件。當發現超時時，查詢優化器停止優化過程並返回到目前爲止找到的最便宜的計劃。此超時事件還顯示在圖形式計劃的屬性中，作爲語句優化的提前終止原因或XML計劃中的StatementOptmEarlyAbortReason。

你可以看一下各個階段使用以下DMV以及

sys.dm_exec_query_optimizer_info 

Paul White也印證了在他的博客一樣..

優化器也會在開始設置一個預算對於優化「移動」數量的階段來說，它認爲足以找到一個很好的計劃（記住優化器的目標是快速找到一個足夠好的計劃）。如果在一個階段中探索和實施替代方案的過程超過了這個「預算」，階段將以「超時」消息告終。 提前終止（無論出於何種原因）是優化程序設計的一部分，完全正常，並且通常不會引起關注。

Further reading ..

Query Optimizer Deep Dive系列由保羅·白

Answer 2

因爲我們的級聯刪除，你有2個觸發器在同一時間更新在同一個表的同一記錄相同的列。他們每個人都想鎖定它，但必須等待另一個，並給你一個超時。

級聯刪除是不是一個好主意，最好是寫的代替觸發刪除表1，可以在表2中刪除子記錄，並做一切必要的loggging。