查詢優化中的迫切需要，但我不知道如何去優化它

我有以下查詢查詢優化中的迫切需要，但我不知道如何去優化它

SELECT 
    YEAR(N.TICKETDATE) AS TICKETYEAR, 
    MONTH(N.TICKETDATE) AS TICKETMONTH, 
    SUM(DISTINCT N.NETWEIGHTHAULED)/COUNT(DISTINCT N.NETWEIGHTHAULED) AS NETTONSHAULED , 
    COUNT(N.TICKETID) AS TICKETCOUNT, 
    COUNT(DISTINCT N.TICKETID)/MAX(DATEDIFF(D,N.TICKETDATE,(DATEADD(M,1,N.TICKETDATE))))AS AVGPERDAY  
FROM 
    AX2009_1_COPY.DBO.NAT_JOBLINE N 
     INNER JOIN AX2009_1_COPY.DBO.SALESLINE S 
     ON N.SALESID = S.SALESID 
     INNER JOIN AX2009_1_COPY.DBO.CUSTINVOICEJOUR J 
     ON N.SALESID = J.SALESID 
WHERE 
    J.INVOICEID NOT LIKE 'CCR%' AND 
    N.TICKETID NOT LIKE 'DMTKT%' 
GROUP BY 
    YEAR(N.TICKETDATE), 
    MONTH(N.TICKETDATE) 
ORDER BY 
    YEAR(N.TICKETDATE), 
    MONTH(N.TICKETDATE)

它需要12分鐘來運行。我不太確定如何縮短查詢的時間。我知道這些連接可能會使用一些工作，但我很難找到真正有用的東西。你能幫我一下，給我一些指點或一個好的網站來找到答案嗎？

來源

2011-08-23 Maximus

「可怕」而不是「戴爾」！ – koan

你沒有說明你的表上是否有任何索引。這表明你不知道索引的重要性。那麼，你對錶格有什麼索引，以及數據量如何？ –

感謝您的英語課:-) – Maximus

開始通過查看執行計劃，以確定哪些查詢的部分導致它運行緩慢。如果你要用SQL Server做任何工作，這是你應該知道如何去做的。這裏有一些像樣的文章值得一讀：

一旦你檢查，你可能能夠確定是否索引的創建可以提高性能的執行計劃。

另一種選擇是創建包含你的持續彙總數據的形式索引視圖。這可以使你免於在運行時做這些計算...

祝你好運！

來源

2011-08-23 21:19:04

謝謝這些文章非常有用！我將在這裏深入閱讀這些提示，看看發生了什麼 – Maximus

首先我會確保你有外鍵索引。我建議你考慮一下，無論你是否可以創建人爲的INT id，而不是使用varchar ID作爲ticket和invoice。您可以考慮在數據庫中添加兩列：年份和月份，因爲如果使用年份（日期），則不能使用索引。最後，我想在正是這種爲了營造invoiceid，ticketid，年，月綜合指數，因爲在這個順序它們出現在你的查詢

UPDATE：

其實更好的辦法是通過別人，首先建議你應該調查什麼是你慢速查詢的真正問題。雖然你可能想使用我的一些想法

來源

2011-08-23 21:20:49 mkk

一般來說，見我的回答一個相關的問題here。如果不這樣做，你不會真正知道什麼是錯的。

如果我絕對不得不猜測，我會懷疑它是對Date函數結果的分組，並選擇性地將這些日期非規範化到具有Year和Month列的DateParts表中。

來源

2011-08-23 21:21:54

查詢優化中的迫切需要，但我不知道如何去優化它

回答

相關問題