我认为DATETIME2是存储日期的更好方法，因为它比DATETIME。在SQL Server 2008中，您可以使用DATETIME2，它存储日期和时间，需要6-8个字节，精度为100纳秒。因此，任何需要更高时间精度的人都会想要DATETIME2。

我同意@marc_s和@Adam_Poward的观点——DateTime2是前进的首选方法。它的日期范围更广，精度更高，使用的存储量相等或更少（取决于精度）。

然而，讨论中遗漏了一件事。。。@Marc_s状态：这两种类型都映射到.NET中的System.DateTime-没有区别。这是正确的，然而，相反的是不正确的。。。在进行日期范围搜索时很重要（例如“查找2010年5月5日修改的所有记录”）。

.NET版本的Datetime具有与DateTime2相似的范围和精度。将.net Datetime向下映射到旧的SQL Datetime时，会发生隐式舍入。旧的SQL DateTime精确到3毫秒。这意味着11:59:59.997将尽可能接近一天的结束。任何更高的值都将舍入到第二天。

试试看：

declare @d1 datetime   = '5/5/2010 23:59:59.999'
declare @d2 datetime2  = '5/5/2010 23:59:59.999'
declare @d3 datetime   = '5/5/2010 23:59:59.997'
select @d1 as 'IAmMay6BecauseOfRounding', @d2 'May5', @d3 'StillMay5Because2msEarlier'

避免这种隐式舍入是转移到DateTime2的一个重要原因。日期的隐式舍入显然会引起混淆：

SQL Server中奇怪的日期时间行为http://bytes.com/topic/sql-server/answers/578416-weird-millisecond-part-datetime-data-sql-server-2000-aSQL Server 2008和毫秒http://improve.dk/archive/2011/06/16/getting-bit-by-datetime-rounding-or-why-235959-999-ltgt.aspxhttp://milesquaretech.com/Blog/post/2011/09/12/DateTime-vs-DateTime2-SQL-is-Rounding-My-999-Milliseconds!.aspx公司

虽然datetime2提高了精度，但有些客户端不支持date、time或datetime2，并强制您转换为字符串文本。微软特别提到了ODBC、OLE DB、JDBC和SqlClient这些数据类型的“底层”问题，并有一个图表显示了它们如何映射类型。

如果值兼容性超过精度，请使用datetime

datetime2在除（旧应用兼容性）之外的大多数方面都获胜

较大的值范围更好的准确性较小的存储空间（如果指定了可选的用户指定精度）

请注意以下几点

语法datetime2[（小数秒精度=>低于存储大小）]精度，刻度0至7位，精度为100ns。默认精度为7位数。存储大小精度小于3时为6字节；精度3和4为7字节。所有其他精度要求8字节。DateTime2（3）的位数与DateTime相同，但使用7字节的存储，而不是8字节（SQLHINTS-DateTime Vs DateTime2）查找有关datetime2的详细信息（Transact-SQL MSDN文章）

图像来源：MCTS自学训练套件（考试70-432）：Microsoft®SQL Server®2008-实施和维护第3章：表格->第1课：创建表格->第66页

接受的答案很好，只需知道，如果您向前端发送DateTime2，它将四舍五入到正常的DateTime等效值。

这给我带来了一个问题，因为在我的解决方案中，我必须在重新提交时将发送的内容与数据库中的内容进行比较，而我的简单比较“==”不允许舍入。所以必须添加它。

如果您是Access开发人员，试图将Now（）写入相关字段，则DateTime2会造成严重破坏。刚刚执行了Access->SQL 2008 R2迁移，它将所有日期时间字段作为DateTime2放入。当值爆炸时，用Now（）追加一条记录。2012年1月1日下午2:53:04没事，但2012年10月1日凌晨2:53:44没有。

一旦性格改变了。希望它能帮助到某人。