DATETIME2的日期范围为“0001/01/01”到“9999/12/31”，而DATETIME类型仅支持1753-9999年。

此外，如果需要，DATETIME2可以在时间方面更精确；DATETIME限制为3 1/3毫秒，而DATETIME2可以精确到100ns。

这两种类型都映射到.NET中的System.DateTime-没有区别。

如果您有选择，我建议尽可能使用DATETIME2。我看不出使用DATETIME有什么好处（除了向后兼容）-你会有更少的麻烦（日期超出范围和麻烦）。

另外：如果您只需要日期（没有时间部分），请使用date-它与DATETIME2一样好，也可以节省空间！：-）同样只适用于时间-使用time。这就是这些类型的原因！

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

Select ValidUntil + 1
from Documents

上面的SQL不适用于DateTime2字段。它返回错误“操作数类型冲突：datetime2与int不兼容”

添加1以获得第二天，这是开发人员多年来一直在使用日期的做法。现在微软有了一个超级新的datetime2字段，无法处理这个简单的功能。

“让我们使用比旧型号更糟糕的新型号”，我不这么认为！

几乎所有的答案和评论都是赞成者居多，反对者较少。这里是到目前为止所有优点和缺点的总结，以及一些关键缺点（在下面的#2中），我只见过一次或根本没有提到。

赞成的意见：

1.1.更符合ISO（ISO 8601）（尽管我不知道这在实践中是如何发挥作用的）。

1.2.更多的范围（1/1/0001至12/31/9999与1/1/175-32/31/9999）（尽管1753年之前的额外范围可能不会被使用，但历史、天文、地质等应用程序除外）。

1.3.与.NET的DateTime Type的范围完全匹配（尽管如果值在目标类型的范围和精度范围内（以下Con#2.1除外，否则将发生错误/舍入），则两者都可以进行来回转换，无需特殊编码）。

1.4更高的精度（100纳秒，即0.0000000,1秒，而3.33毫秒，即0.003,33秒）（尽管除了工程/科学应用程序外，可能不会使用额外的精度）。

1.5.当配置为与DateTime的精度类似（如Iman Abidi所宣称的1毫秒，而不是“相同”（如3.33毫秒））时，使用的空间更少（7字节对8字节），但当然，您将失去精度优势，这可能是最受吹捧的两个（另一个是范围）之一，尽管可能是不必要的优势）。

欺骗：

2.1.将参数传递给.NET SqlCommand时，如果传递的值超出了SQL Server DateTime的范围和/或精度，则必须指定System.Data.SqlDbType.DateTime2，因为它默认为System.Data.SqlDbType.Date Time。

2.2.无法隐式/轻松地转换为浮点数字（自最小日期时间起的天数）值，以便在SQL Server表达式中使用数值和运算符对其执行以下操作：

2.2.1增加或减少天数或部分天数。注意：当您需要考虑日期时间的多个部分（如果不是全部的话）时，使用DateAdd函数作为一种解决方法并不简单。

2.2.2.为了计算“年龄”，取两个日期时间之间的差值。注意：您不能简单地使用SQL Server的DateDiff函数，因为它不会像大多数人预期的那样计算年龄，因为如果两个日期时间恰好跨越指定单位的日历/时钟日期时间边界，即使是该单位的一小部分，它也会返回该单位的1与0之间的差值。例如，如果两个日期时间在不同的日历日（即“1999-12-31 23:59:59.9999999”和“2000-01-01 00:00:00.0000000000”），则仅相隔1毫秒的日期时间的Day中的DateDiff将返回1与0（天）。如果移动相同的1毫秒差的日期时间，使其不跨越日历日，则Day中返回0（天”的“DateDiff”。

2.2.3.通过先转换为“浮点”，然后再转换为DateTime，获取日期时间的平均值（在聚合查询中）。

注意：要将DateTime2转换为数字，您必须执行以下公式，该公式仍然假设您的值不小于1970年（这意味着您将失去所有额外范围加上217年）。注意：您可能无法简单地调整公式以允许额外范围，因为您可能会遇到数字溢出问题。

25567+（DATEDIFF（SECOND，｛d'1970-01-01'｝，@Time）+DATEPART（纳秒，@Time）/1.0E+9）/86400.0–来源：“https://siderite.dev/blog/how-to-translate-t-sql-datetime2-to.html “

当然，您也可以先转换为DateTime（如果需要，再转换为DateTime2），但您会失去DateTime2与DateTime2相比的精度和范围（在1753年之前）的优势。DateTime是最大的2个，同时也是最不可能需要的2个。这就引出了这样一个问题：当您丢失了对浮点数字（天数）的隐式/简单转换时，为什么要使用它进行加法/减法/“年龄”（与DateDiff相比）/平均计算，这在我的经验中是一个很大的好处。

顺便说一句，日期时间的平均值是（或者至少应该是）一个重要的用例。a） 除了在使用日期时间（由于通用基准日期时间）表示持续时间（一种常见做法）时用于获取平均持续时间外，b）还可以获得一个仪表板类型的统计信息，该统计信息显示行范围/行组的日期时间列中的平均日期时间。c） 一个标准（或至少应该是标准）的特殊查询，用于监视/排除列中可能不再有效和/或可能需要弃用的值，即列出每个值的出现计数以及与该值关联的最小、平均和最大日期时间戳（如果可用）。

datetime2更好

日期时间范围：1753-01-01到9999-12-31，日期时间2范围：0001-01-01到9999-12/31datetime精度：0.0033秒，datetime2精度：100纳秒datetime获取8个字节，datetime2获取6到8个字节取决于精度（精度小于3时为6字节，精度3或4时为7字节，所有其他精度要求8字节，单击并查看下图）

老问题。。。但我想补充一些这里没有人说过的话。。。（注：这是我自己的观察结果，所以不要要求任何参考）

在筛选条件中使用Datetime2更快。

TLDR：

在SQL 2016中，我有一个包含十万行和日期时间列ENTRY_TIME的表，因为它需要存储精确到秒的时间。当我使用where子句作为：

WHERE ENTRY_TIME >= '2017-01-01 00:00:00' AND ENTRY_TIME < '2018-01-01 00:00:00'

最初，当有数百行时，查询很好，但当行数增加时，查询开始出现以下错误：

Execution Timeout Expired. The timeout period elapsed prior
to completion of the operation or the server is not responding.

我删除了where子句，出乎意料的是，查询在1秒内运行，尽管现在所有日期的所有行都已提取。我用where子句运行内部查询，用了85秒，没有where子句用了0.01秒。

我在这里遇到了许多关于日期时间过滤性能的线程

我优化了一下查询。但我得到的真正速度是将datetime列更改为datetime2。

现在，以前超时的同一个查询只需要不到一秒钟的时间。

干杯