使用Date vs DateTime時是否存在性能差異或存儲差異？

Question

使用SQL Server & ASP.NET時，在使用Date與DateTime時是否存在性能/存儲方面的考慮因素？

即使我並不需要它，我一直在使用DateTime對大多數事情

Answer 1

日期時間需要每個值8個字節

日期是3個字節。

我不能說低水平的表現;然而，通常我們發現在默認情況下將值存儲爲DateTime是個錯誤。您遲早會遇到UTC問題，並且必須開始計算時間部分中具有00：00：00.000的日期的偏移量！

如果你只是存儲日期，我會堅持日期數據類型;您將每頁適合更多行併爲您節省大量麻煩

Answer 2

取決於您要存儲的行數以及您使用的行數。日期是3個字節，日期時間是8個字節。當你擁有數十億行數據或者將它用於索引時，可以快速加起來。當然，存儲值的分辨率也有差異。日期和日期時間之間還有其他日期類型，例如smalldatetime，它們更加緊湊，並且具有不同的折衷。

SQL Date/Time Types Documentation

Answer 3

考慮：

• 性能：日期型更少的位表示每個SQL頁更多的行（數據頁或索引頁）裝置少頁，以在執行讀取查詢
• 兼容性：DATE類型在SQL Server 2008中引入，因此您的應用程序與SQL Server 2005不兼容
• .NET：沒有Date類在.NET - DATE轉化爲DateTime .NET類
• LINQ：LINQ2SQL（和SQL金屬工具）與DATE SQL類型
• 你可能會突然小時和分鐘從DATETIME順利做CAST(@myDateTimeParam AS DATE)

從我的經驗：我喜歡這個新類型，也沒有與它的問題，而編程的T-SQL或C＃

注意這一點（混合數據類型DAT E在特點比較）：

DECLARE @startDay DATE = '2012-04-11' -- day 
DECLARE @endDay DATE = '2012-04-13' -- day 
DECLARE @eventTime DATETIME = '2012-04-13 12:00' -- point in time (noon) 

IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!' 

結果是：

Not in period! 

在BETWEEN特點比較@endDay澆鑄至DATETIME（在時間點;與@eventTime共同類型），我想 - 什麼給不直觀的結果。

比較：

DECLARE @startDay DATE = '2012-04-11' -- day 
DECLARE @endDay DATE = '2012-04-13' -- day 
DECLARE @eventTime DATE = '2012-04-13' -- day 

IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!' 

結果：

In period. 

而且它：

DECLARE @startDay DATETIME = '2012-04-11' -- day, but point in time in fact 00:00.000 
DECLARE @endDay DATETIME = '2012-04-13' -- day, but point in time in fact 00:00.000 
DECLARE @eventTime DATETIME = '2012-04-13' -- day, but point in time in fact 00:00.000 

IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!' 

結果：

In period.