我有一個非常噁心的存儲過程，幾個月前並不慢，但現在是。我幾乎不知道這件事是什麼，我也沒有興趣重寫它。Sql Server 2000存儲過程阻止並行或什麼？
我知道，如果我拿着存儲過程的主體，然後聲明/設置參數值並在查詢分析器中運行它，它運行速度提高了20倍以上。
從互聯網上，我讀到，這可能是由於一個不好的緩存查詢計劃。所以，我試過在EXEC之後用「WITH RECOMPILE」運行sp，並且我也嘗試過在內部放置「WITH RECOMPLE」，但這兩者都沒有幫助。
當我查看sp與查詢的執行計劃時，最大的區別是sp在整個地方都有「並行性」操作，查詢沒有任何操作。這可能是速度差異的原因嗎？
謝謝，任何想法都會很棒......我被卡住了。
如果兩個查詢計劃之間的唯一區別是並行性，請嘗試將OPTION (MAXDOP 1)放在查詢的末尾以將其限制爲序列計劃。至於爲什麼它們不同，我不確定，但我記得SQL Server 2000優化器是這樣的，呃，finicky。與您的情況類似，我們通常看到的是臨時查詢批次會很快，而通過sp_executesql進行的相同查詢會很慢。從未完全弄清楚發生了什麼事。儘管如此，串行並行可以明確地解釋速度的不同。在SQL Server 2000上，並行計劃use all the processors on the machine不僅僅是它需要的那些：
如果SQL Server選擇使用並行性，它必須使用所有配置的處理器（由MAXDOP查詢提示配置確定）執行平行計劃。例如，如果在32路服務器上使用MAXDOP = 0，則與僅使用一個處理器的串行計劃相比，即使七個處理器可以更有效地執行作業，SQL Server也會嘗試使用全部32個處理器。由於這種全有或全無的行爲，如果SQL Server選擇並行計劃並且不限制MAXDOP查詢提示[...]，那麼需要SQL Server協調高端服務器上所有處理器的時間超過使用並行計劃的優勢。
默認情況下，我認爲服務器範圍內的MAXDOP設置爲0，表示儘可能多地使用。如果您最近使用更多處理器升級了數據庫服務器以提高性能，這可能會諷刺地解釋您的性能受到影響的原因。如果是這樣的話，你可以嘗試設置MAXDOP提示以前的處理器數量，看看是否有幫助。
我知道，如果我帶的 存儲過程中的身體，然後 聲明/設置 參數的值，並在查詢運行它，它運行超過20倍 更快 分析。
你確定它不是在SP執行之前獲取這些參數嗎？這不會導致你的緩慢？繞過這些參數的人羣，你可能會過分簡化你的問題。
這些參數從何而來？他們是如何填充的？從你的問題看來，你已經隔離了存儲過程並發現它可能不是問題。
嘗試在過程的頂部添加SET ARITHABORT ON。
很高興知道，但這也沒有幫助。我想我應該提及它沒有進行任何聚合或計算。不過謝謝。 – 2010-03-19 14:26:52
如果您已經對報表進行了很多的變化，而不是運行重新索引或碎片整理上有問題你應該表。看看這article。我建議這樣做的原因是因爲程序一度很快，現在隨着時間的推移它的性能下降了。我不認爲對已經測試過並且一次很好運行的已有程序的更改應該隨着時間的推移而發生變化，因爲這會改變性能。這通常只處理症狀而不是實際問題。
完全有效，我會試一試。但是，我想我對這個時候存儲過程出了什麼問題更感興趣。例如，如果索引完全分散，那麼常規查詢如何解決這個問題並仍然很快？ – 2010-03-19 14:35:20
它可能是一個爭用問題嗎？此商店程序是否在特定時間運行，此時還有其他繁重事件發生？
我很難編碼我的參數。我在查詢分析器中字面上有以下內容。創建程序someProc（@a int）*** body *** go EXEC someProc 5 ------------------------------- - 聲明@a int set @ a = 5 *** body ***我突出了EXEC語句，它需要24秒。我強調了這個查詢，它需要1秒。 – 2010-03-19 14:25:17