Hunterpo's IT Vision

歡迎一起分享 C#、T-SQL、ASP.NET 開發心得

2010-11-30

利用 T-SQL 產生日期清單 (萬年曆) 並測試日期轉民國年函數對效能影響

利用 T-SQL 產生日期清單 (萬年曆) 並測試日期轉民國年函數對效能影響

前陣子分享了 SQL Server 日期轉民國年格式函數，當時保哥提到在人多的網站要注意效能問題，當下差點將「咱家網站特色就是人數不多」這秘密脫口而出，還好我口風很緊…，然而這幾個月除了當「守密人」之外，其實也想了解一下到底套用日期轉民國年格式函數對效能傷害大不大，重點是說，要測試就得有足夠的樣本才有參考價值，因此本文首先就分享如何在 SQL Server 裡產生日期清單的小技巧，其實挺容易的，參考下列語法： 

SELECT @sdate = '19120101', @edate = '29101231';

;WITH cte AS (
	SELECT [date] = @sdate
	UNION ALL
	SELECT [date] + 1 FROM cte WHERE ([date] < @edate)
)
SELECT [date]
FROM cte
OPTION (MAXRECURSION 0);
GO

利用 SQL Server 2005 以後支援的遞迴式 CTE 可以輕鬆完成此一需求，起始、結束日期限定在西元 1912 年以及 2910 年，目的是讓民國年落在 1 ~ 999 區間。(想產生萬年曆的人請自行修改區間)

接著就來套轉民國年函數看看，底下是測試截圖：

cte_getdates
cte_getdates_tw

套用前後執行時間增加了 5 秒以上，不過這是將近一千年的天數所累積的處理時間，除非是千年修為的蜘蛛精，不然不會有機會這樣用吧？來看看人類比較有可能用到的，列出 5 年的日期：

cte_getdates_5y
cte_getdates_5y_tw

由數據顯示，耗時的增加應該還在可接受的範圍，這也是為什麼我在分享文章中回覆效能影響應該不明顯。(其實我甚至測過 10 年的天數，結果仍舊是影響不大)

結論是：以本例來說，轉民國年函數只用在 SELECT 最終輸出，而不是 WHERE 篩選欄位的前提下，對效能的影響不大，因此有需要的人請安心服用吧。

系列文章

標籤雲