如何分析慢速查詢？

我們有這個數據庫應用程序不斷運行一個複雜的查詢與不同的參數。它是一個編譯存儲過程（C＃），它調用將4到6個表連接在一起的4個正常存儲過程，並將C＃代碼合併到調用之間的結果中。如何分析慢速查詢？

這一直運行良好（快）6個月，直到數據庫恢復。然後，表演從幾乎瞬間變爲20秒以上。谷歌搜索清楚地表明，更新統計數據必須在表格上運行，是的，它的工作，再次即時查詢。

但是這個問題在一個月後回來了。好的沒問題，再次更新統計信息。再次快速。然後花了一個星期纔回來。慢速查詢出藍色。然後問題不斷回來，越來越快，在這一點上更新統計數據根本無濟於事。

如何分析這類問題？是否需要了解有關編譯存儲過程和查詢計劃的性能？

來源

2013-11-04 Laurijssen

這聽起來很「典型的參數嗅探」。如果這是常規的TSQL，我會建議'優化FOR（... UNKNOWN）'提示作爲第一個嘗試 - 我不知道如何轉換爲*編譯*（C＃）存儲過程。 –

我認爲表需要索引。在表上創建索引。使用SQL Server Profiler和另一個我不記得的工具將分析查詢並告訴您是否需要索引優化/創建。

索引應該處理緩慢的查詢。此外，查詢中還有其他一些內容應該像少數表一樣查看，主要ID上的聯接等。

來源

2013-11-04 08:34:00 iefpw

說「索引應該照顧緩慢的查詢」過於簡單 - 現實更加微妙。另外，我有點懷疑正在編寫sprocs的人知道如何創建一個索引。 –

假設數據庫屬性爲MSSQL;選項，檢查「自動更新統計」是否爲真。如果它被設置爲False，但它是一種可能性，這將是非常罕見的。

來源

2013-11-04 08:40:30 smoore4

你應該去「分而治之」:)。

這4個正常的存儲過程如何在編譯的SP之外進行？你可以單獨運行它們嗎？他們每個人的執行計劃看起來不錯？你是否爲他們每個人使用索引？（正確使用索引應轉換爲執行計劃中的Index Seek操作，理想情況下爲Clustered Index Seek操作）

如果這些看起來不錯，那麼請查看編譯後的存儲過程。尋找可能的瓶頸，特別是在連接大量數據時。

我個人也同意這可以通過適當的索引來解決。

當缺少索引時，SQL Server正試圖根據統計信息優化代碼的執行。統計信息可能與數據不同步，所以當它們不是最新的時，SQL Server可能無效地運行你的代碼。

但是，當你定義索引時，你基本上是告訴SQL Server如何最優地執行你的查詢。

來源

2013-11-04 08:49:48 Lucian

性能調整應該逐步處理，首先嚐試根據表和表上的現有索引調整查詢。這可以通過適當的連接，避免通配符，聯合等等，可以通過使用執行計劃。如果您準備好了查詢，則可以檢查在列上創建更多索引是否會提高查詢性能。請記住，新索引可能會增加「SELECT」查詢的性能，但可能會降低UPDATE，INSERT，DELETE的性能。

來源

2013-11-04 08:50:35 PKV

如何分析慢速查詢？

回答

相關問題