隨着時間的推移性能降低

這是我的第一篇文章，所以如果你需要澄清任何東西，然後讓我知道。隨着時間的推移性能降低

我的服務器的詳細信息如下： - 的Windows 2008數據中心版
SQL 2008標準版（10.0.1600）
12GB拉姆
四核單處理器的機器

問題
我有一個運行的存儲過程，當我剛啓動SQL時，大約需要1/10秒才能運行。經過一段時間後，運行相同的查詢需要大約3秒的時間。

我原本以爲是引起問題的索引，但是如果我製作精確的副本並運行復制的版本，那麼該查詢現在只需要1/10秒，而原始的仍然需要3秒。

我現在假設它是與正在緩存的sproc的執行計劃有關，並且當sproc再次運行時，它正在搞亂執行計劃。

事情我至今
我目前有每隔15分鐘重新索引的小桌子和執行出於某種原因，時間運行在我的存儲過程的維護計劃回落到正常水平，但隨後嘗試時代突然再次回升。

創建了一個sproc副本來測試它，並且一個在1/10秒運行，而原始的仍然需要很長時間。

運行「更新統計信息」sproc以確保所有統計信息都是最新的。

Ran SQL查詢分析器查看是否對應該在表上的其他索引提出了任何建議，最終提出了一些建議，將索引和db大小增加到70gb以上，並且性能增加可以忽略不計。

其他信息需要注意
的DB是傳播防空火炮在同一例如，兩個DBS，一個包含產品信息，另一個包含客戶信息。

其中一個連接表是1.3億行。

的DB是升級從2005年至2008年

是什麼存儲的過程嗎？我們能看到一些簡短的邏輯代碼嗎？ – 2010-09-27 12:51:04

這似乎是參數嗅探給我。

您的15分鐘重新索引（您是否需要！？）將導致依賴過程被重新編譯。有時候會發生這種情況，在下一次執行時傳遞的參數值在一般情況下是次優的。您可以使用OPTIMIZE FOR來防止發生這種情況。

2010-09-27 12:50:27

我每15分鐘執行一次重新索引，以便查詢再次正常執行。一旦小的重新指數發生，它們又會下降到1/10秒？這是什麼讓我相信這是執行計劃或某種參數緩存 – 2010-09-27 12:58:21

@Chris - 我會消除重新索引並使用'OPTIMIZE FOR UNKNOWN'提示。 – 2010-09-27 13:00:21

感謝馬丁，我打算繼續努力，看看我是否看到任何性能提升。或者說，沒有退化。 – 2010-09-27 13:16:27

這看起來像是由參數嗅探引起的。這裏是一個很好的解釋：

2010-09-27 12:51:30 Giorgi

我已經有很多參數已經存在，並且查詢的形狀實際上並不會因不同的參數而改變。查詢中的參數是日期，客戶ID，類別ID等。我將在稍後進一步研究該文章。 – 2010-09-27 12:54:56

@Chris - 這不關於查詢的形狀。例如，問題在於，如果程序編譯時使用的參數異常選擇，則可能會得到一個不同的計劃，其索引搜索和書籤查找對於選擇性較小的情況不是最佳選擇。 – 2010-09-27 12:55:57

回答