SQL Server查詢運行速度緩慢時更改在哪裏條款

Question

你好，並提前感謝。我有一個觀點，當查詢沒有where子句只需要超過0秒返回〜8600行。然而，當我與查詢的WHERE子句，如：

SELECT * FROM myView WHERE myID = 123 

根據什麼定我到位的123查詢執行時間顯着變化。

現在，在這種情況下「相當」意味着剛好在0秒和3到4秒之間的差異。但是對於某些任務而言，視頻會被頻繁地重複調用，這會使3秒鐘變成30秒或更長時間。

雖然我不能給出視圖本身的代碼，我可以確認的是，：

1. 視圖是由6個標準表（沒有特殊的品質）的接合的。

2. 儘管表A中可能並不總是有與表B連接的記錄，因此在結果中創建了空列，但我已經確認這些實例並不總是導致查詢時間更長或更短。

3. 視圖本身沒有超出標準Select，From和Left Outer Join子句的子句。

4. 某些標識總是導致很長的查詢時間和其他人總是會存在較短的查詢時間

5. 我已經下降，創造了在查詢之間的視圖上起飛的機會，有這是一個緩存的執行計劃次優的。

如果這些已知的變量是不夠的，以減少可能下降到2倍或3個可能的原因我還是想知道是什麼理論問題可能會造成這個問題只是擴大我的理解。

再次感謝，

ProtoNoob

Answer 1

我會假設，這些表的統計數據已經過時，不符合表的實際內容。這意味着優化器依靠統計信息e。 G。假定您在WHERE子句中使用的值根本不會在數據中發生，因此結果集相當小，而實際上它包含很多行。或者相反：依據統計信息，優化器可以假設 - 例如 - 表中有20％的行具有該值，因此最好執行全表掃描，而不是首先訪問索引頁以進行評估where條件，然後跳轉到幾乎每個索引條目的數據頁以讀取數據，最後不得不閱讀幾乎所有的頁面。或者它會以錯誤的順序訪問表格，或者......但實際上，表格根本不包含該值，因此只會導致錯誤的計劃。

如果查詢計劃顯示估計行數與實際行數之間存在巨大差異，則會提示指向過期統計信息。

您正在使用哪些DBMS？如果使用SQL Server，則可以使用DBCC SHOW_STATISTICS查看當前統計信息，並使用UPDATE STATISTICS語句刷新所選列和表的統計信息。圍繞這個問題有更多的觀點和程序，其中大部分都與這兩篇文章中的一篇相關聯。