SQL Server性能和更新統計信息

Question

我們有一個正在開發的網站，當我們將它部署到客戶端的生產服務器時，我們在幾個小時後開始查詢超時。

這是與單個用戶測試它與我們的服務器（這是在SQL Server版本號上是相同的 - 2005 SP3）上，我們從未有過同樣的問題。

我們的一個高級開發人員曾在之前的工作中遇到類似的行爲，他跑了查詢手動更新統計和問題奇蹟般地走了 - 查詢在幾毫秒爲單位返回。

幾個小時後，發生了同樣的問題。所以我們再次手動更新統計數據，並再次出現問題。我們已經檢查了數據庫屬性，並確定自動更新統計信息isTRUE。

作爲一種臨時措施，我們已經設定了一項任務來定期更新統計數據，但顯然這不是一個好的解決方案。

誰遇到這個問題的開發商面前是肯定它是一個環境問題 - 當它發生了他之前，它走它自己的協議後幾天。

我們檢查了他們的數據庫服務器上的SQL服務器安裝，這不是我認爲是正常的。雖然他們安裝了SQL 2005（而不是2008），但安裝目錄中有一個空的「100」文件夾。還有MSQL.1，MSQL.2，MSQL.3和MSQL.4（這是可執行文件和數據實際存儲的地方）。

如果任何人有任何想法，我們會很感激 - 我說，而不是統計數據沒有更新，他們已經在某種程度上成爲腐敗的意見。

非常感謝

託尼

Answer 1

是不是統計信息過時。當更新統計數據時，會發生什麼情況，所有計劃都會失效，並且一些壞的緩存計劃會被驅逐。事情運行順利，直到一個糟糕的計劃再次被緩存並導致執行緩慢。

真正的問題是你爲什麼得不到很好的計劃開始嗎？我們可以進入冗長的技術和哲學論點，無論查詢處理器是否會創建一個不好的開始計劃，但事實是，當應用程序以某種方式編寫時，可能會發生錯誤的計劃。典型的例子是有一個where子句，如(@somevaribale is null) or (somefield= @somevariable)。最終99％的不良計劃可以追溯到開發人員編寫具有C風格程序期望的查詢，而不是基於聲音，基於集合的關係處理。

你現在需要做的是找出的壞查詢。真的很容易，只需檢查sys.dm_exec_query_stats，不好的查詢將在total_elapsed_time和total_logical_reads方面脫穎而出。一旦你確定了錯誤的計劃，你可以採取糾正措施，從查詢查詢。

Answer 2

與萊姆斯意見分歧......

參數嗅探允許SQL Server猜測最優規劃寬範圍的輸入值。有些時候，這是錯誤的，由於非典型價值或缺乏選擇，這個計劃很糟糕。

我以前可以通過在0和NULL之間更改默認值來按需演示：計劃和性能發生了顯着變化。

統計信息更新將使計劃失效。查詢將因此被編譯並在下次使用

的解決方法是其中的一個緩存如下：

• 參數掩蔽
• 使用OPTIMIZE FOR UNKNOWN提示
• 複製「默認」

查看這些SO問題

• Why does the SqlServer optimizer get so confused with parameters?
• At some point in your career with SQL Server does parameter sniffing just jump out and attack?
• SQL poor stored procedure execution plan performance - parameter sniffing
• Known issue?: SQL Server 2005 stored procedure fails to complete with a parameter
• ...and Google search on SO

現在，萊姆斯工程爲SQL Server開發團隊。然而，這種現象是深受微軟證明自己的網站，所以罵開發商是不公平的

• How Data Access Code Affects Database Performance（MSDN MAG）
• Suboptimal index usage within stored procedure（MS連接）
• Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005（良好的白色紙）