使用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.