Sql Server查詢優化

我正在優化一個使用大量動態Sql的Sql Server 2008中的大型SP。這是一個查詢，它使用一些可選參數搜索數據庫，並且對每個可能的參數組合都進行編碼。動態sql已被證明是執行此操作的最有效方法。 sql striung包含參數，然後通過參數列表傳遞給sp_executesql。當使用任何參數組合運行SSMS時，它運行速度非常快（< 1秒）並返回結果。但是，從Windows窗體應用程序運行時，它有時需要相當長的時間。Sql Server查詢優化

我讀過ARITHABORT選項中的差異可能會導致這種情況（在SSMS中默認爲ON，在ADO中爲OFF），但我不確定是否打開此項可修復問題還是掩蓋了它？設置上的差異是否會對查詢本身產生影響？或者這是否意味着Sql Server將使用不同的緩存執行計劃？如果是的話應該清除緩存和統計數據重置場地？

我也讀過關於OPTION RECOMPILE設置的不同觀點。我的理解是，當sp_executesql與參數列表一起使用時，每個參數組合將產生一個執行平面，但是由於參數的可能組合是有限的，這將導致優化的查詢。其他消息來源說，在任何使用動態sql的SP開始時，它應該設置爲ON。

我意識到不同的情況需要不同的設置，但我期待在我非常繁忙的24x7生產服務器上嘗試arbritraily之前瞭解這些。道歉，我想我的問題歸結爲：

是什麼原因導致SQL在SSMS和窗體窗體中運行不同？如果是ARITHABORT，那麼這是一個與執行計劃相關的問題還是應該將其作爲服務器默認設置打開？使用動態sql運行查詢的最佳方式是什麼？

來源

2010-09-17 Macros

你可以在測試服務器上嘗試更改嗎？一般來說，無論「應該」工作，YMMV – Beth 2010-09-17 15:37:30

@Beth - 我會嘗試在測試服務器上進行更改，但我主要關心的是更改內容。設置ARITHABORT可能會解決問題，但如果它實際上只是讓ADO查看不同的執行計劃，這看起來不像修復。我的生產數據庫的尺寸也比我的測試大很多，儘管我意識到這並不理想，但我目前沒有足夠大的測試服務器來完全複製生產環境。 – Macros 2010-09-17 15:55:10

你見過http://articles.techrepublic.com.com/5100-10878_11-5662581.html – Beth 2010-09-17 16:00:32

在SQL事件探查器中運行跟蹤以查看實際提交到服務器的內容。當然，您需要了解生產服務器上的痕跡的影響。根據我的經驗，僅限於小集的非常短的跟蹤對於沒有每秒負載事務數很高的服務器來說不是一個大問題。此外，您可以運行跟蹤服務器端，從而降低其影響，因此這是您的選擇。

一旦看到實際提交到數據庫的內容，這可能會幫助您瞭解問題。例如，有時DB庫會準備語句（獲取某種臨時存儲過程的句柄），但如果爲每次發出查詢完成此操作，則花費可能很高，而且對於sp_executesql不需要。無論如何，沒有辦法確定它是否會有幫助，直到你嘗試。

來源

2011-02-16 18:57:33 ErikE

Sql Server查詢優化

回答

相關問題