datetime2(0) 与 datetime2(2)

Question

根据文档datetime2 (Transact-SQL)：

存储大小
小于 3 的精度为 6 个
字节。精度 3 和 4 为 7 个
字节。所有其他精度需要 8 个字节。

datetime2(0)、datetime2(1)、的大小datetime2(2)使用相同的存储量（6 字节）。

我是否正确地说，我可能会datetime2(2)在没有任何额外尺寸成本的情况下使用并获得精度的好处？

请注意：

• 该列用PK进行索引，形成复合聚集索引（用于表分区）
• 我不在乎毫秒

datetime2(0)在 where 子句中使用或通过索引查找时，cpu 效率会更高吗？

这是一个庞大的表，因此最小的优化将产生很大的不同。

Answer 1

dateTime2(0)、dateTime2(1)、dateTime2(2)、dateTime2(3)的大小使用相同的存储量。(6 字节)

我是否正确地说我不妨使用 dateTime2(3) 并获得精度的好处，而无需任何额外的尺寸成本。

不，您误解了文档。请注意，文档指出精度小于3 的存储大小为 6 字节（重点是我的）。所以精度等于 3 将需要 7 个字节。

如果您不关心毫秒，datetime2(0)那么将是正确的数据类型和精度。最佳做法是根据存储的数据指定正确的数据类型和精度，因为这将本质上提供最佳存储和效率。话虽如此，只要存储大小相同，我就不会期望基于指定的 datetime2 精度对性能产生重大影响，但我自己还没有专门测试过。

当源中有更高的精度时，应用程序要求将决定必须在数据库中存储什么。例如，对于来自 的订单输入时间SYSDATETIME()，用户可能不想要 100 纳秒的精度。再次，根据需求选择新开发的数据类型和精度，您通常会获得最佳性能而无需额外考虑：

• 日期- 你不需要时间
• smalldatetime - 你不需要秒
• datetime2(0) - 你不需要小数秒
• datetime2(1-7) - 您需要指定精度的小数秒
• datetimeoffset(0-7) - 您需要具有时区意识的日期和时间
• time(0-7) - 您只需要指定精度的秒数的时间（无日期）

尽管 datetime2 最适合上面列出的新开发，但有时可能需要使用datetime（固定精度 3 和 1/300 小数秒精度）来代替旧的 datetime 应用程序的兼容性，从而避免隐式转换和意外的比较行为，但在以小数秒精度和增加存储为代价。

考虑到存储比所需精度更高的精度也可能会产生开发成本。如果在只需要整秒精度的情况下存储带有小数秒的时间组件，查询仍然需要考虑小数秒以返回正确的结果。例如，对于用户通过仅允许整秒的 UI 选择时间范围的应用程序，应用程序代码需要考虑结束时间范围值中的小数秒，并相应地调整用户提供的值（例如WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'或WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'）。这会增加代码的复杂性。