尋找SQL計數性能改進。

我正在重構一些較舊的SQL，這是在4年和1.7m行數據之後掙扎。有沒有改善以下MS SQL查詢的方式：尋找SQL計數性能改進。

SELECT  ServiceGetDayRange_1.[Display Start Date], 
SUM (CASE WHEN Calls.line_date BETWEEN [Start Date] AND [End Date] THEN 1 ELSE 0 END) AS PerDayCount 
FROM   dbo.ServiceGetDayRange(GETUTCDATE(), 30, @standardBias, @daylightBias, @DST_startMonth, @DST_endMonth, @DST_startWeek, @DST_endWeek, @DST_startHour, @DST_endHour, @DST_startDayNumber, @DST_endDayNumber) AS ServiceGetDayRange_1 CROSS JOIN 
         (select [line_date] from dbo.l_log where dbo.l_log.line_date > dateadd(day,-31,GETUTCDATE())) as Calls 
GROUP BY ServiceGetDayRange_1.[Display Start Date], ServiceGetDayRange_1.[Display End Date] 
ORDER BY [Display Start Date]

它在過去30天計數日誌條目（ServiceGetDayRange函數返回表，詳細範圍，TZ對齊）密謀圖表..無用的信息，但我不是客戶。

執行計劃規定執行時間的99％用於計算條目..正如您所期望的那樣。在計算TZ偏移時很少有開銷（記住最多30行）。

愚蠢我以爲'啊，索引視圖'，但後來意識到我不能綁定到一個函數。

當前執行時間，如果6.25秒。任何改善+ rep

在此先感謝。

來源

2010-02-11 Sean.C

如果您將CASE轉變爲WHERE，速度會更快嗎？

SELECT  ServiceGetDayRange_1.[Display Start Date], COUNT(*) AS PerDayCount 
FROM  dbo.ServiceGetDayRange(GETUTCDATE(), 30, @standardBias, @daylightBias, @DST_startMonth, @DST_endMonth, @DST_startWeek, @DST_endWeek, @DST_startHour, @DST_endHour, @DST_startDayNumber, @DST_endDayNumber) AS ServiceGetDayRange_1 CROSS JOIN 
         (select [line_date] from dbo.l_log where dbo.l_log.line_date > dateadd(day,-31,GETUTCDATE())) as Calls 
WHERE Calls.line_date BETWEEN [Start Date] AND [End Date] 
GROUP BY ServiceGetDayRange_1.[Display Start Date], ServiceGetDayRange_1.[Display End Date] 
ORDER BY [Display Start Date]

來源

2010-02-11 00:50:38

omg ...其整個4.5秒更快...我實際上打折了，因爲我認爲它owuld計數日期範圍（即總是30），您先生，是一個紳士。 – 2010-02-11 00:58:13

很高興聽到它。猜測，我認爲對於CASE來說，它必須訪問每一行並以不可優化的方式評估表達式。 COUNT（*）/ WHERE有機會更好地使用索引，也許... – 2010-02-11 01:06:51

6.25秒爲近200行是相當不錯的..也許嘗試有效行數（您的條件1/0應該允許），而不是值的總和。我認爲這是更有效oracle環境。

來源

2010-02-11 00:51:02 glasnt

我其實也認爲6.25秒並不壞，所有的事情都是一致的，差不多就是這樣 - 很高興我沒有; t。我現在知道基於案例測試的計數並不總是更好。 – 2010-02-11 01:01:24

尋找SQL計數性能改進。

回答

相關問題