幾天前我寫了一個查詢,它得到快速執行,但現在一天需要1小時。 此查詢在我的SQL7服務器上運行,大約需要10秒。 此查詢存在於另一個SQL7服務器上,直到上週它花費了大約10秒鐘的時間。 兩臺服務器的配置相同。只有硬件是不同的。Sql查詢得到太慢
現在,在第二臺服務器上,此查詢大約需要30分鐘才能提取詳細信息,但任何人都已更改了任何詳細信息。
如果我在沒有Where的情況下執行此查詢,它會顯示7 秒內的詳細信息。 這個查詢仍然需要大約相同的時間,如果哪裏是問題
幾天前我寫了一個查詢,它得到快速執行,但現在一天需要1小時。 此查詢在我的SQL7服務器上運行,大約需要10秒。 此查詢存在於另一個SQL7服務器上,直到上週它花費了大約10秒鐘的時間。 兩臺服務器的配置相同。只有硬件是不同的。Sql查詢得到太慢
現在,在第二臺服務器上,此查詢大約需要30分鐘才能提取詳細信息,但任何人都已更改了任何詳細信息。
如果我在沒有Where的情況下執行此查詢,它會顯示7 秒內的詳細信息。 這個查詢仍然需要大約相同的時間,如果哪裏是問題
沒有看到查詢和可能的數據我不能做很多提供提示。
希望這會有所幫助。
不知道多少數據進入你的表,不知道您的架構,很難給出一個明確的答案,但事情來看待:
UPDATE STATS
或DBCC REINDEX
。WHERE
子句和JOIN
謂詞中使用的列添加索引。OR
條款(即,你在哪裏做WHERE table1.col1 = @somevalue OR table2.col2 = @someothervalue
)。 SQL無法使用此構造有效地使用索引,並且可以通過將查詢拆分爲兩個並將結果拆分爲更好的性能。LEFT JOIN
的地方,重新審視邏輯並查看它是否需要成爲LEFT或是否可以變成INNER JOIN。有時候人們會使用LEFT JOIN,但是當您查看查詢其餘部分的邏輯時,有時可以很明顯的看到LEFT JOIN不會給你任何東西(例如,因爲某人可能已經對連接的表添加了一個WHERE col IS NOT NULL
謂詞)。 INNER JOINs可以更快,所以值得重新審視所有這些。如果我們能看到查詢,建議事情會容易得多。
顯示您正在執行的查詢請。 – 2011-02-01 10:10:58