为什么SQL Server丢失一毫秒？

69

我有一个这样的表结构：

CREATE TABLE [TESTTABLE]
(
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [DateField] [datetime] NULL,
    [StringField] [varchar](50),
    [IntField] [int] NULL,
    [BitField] [bit] NULL
)

我执行以下代码：

BEGIN 
   INSERT INTO TESTTABLE (IntField, BitField, StringField, DateField) 
   VALUES ('1', 1, 'hello', {ts '2009-04-03 15:41:27.378'});  

   SELECT SCOPE_IDENTITY()  
END

接着

select * from testtable with (NOLOCK)

我的结果显示：

2009-04-03 15:41:27.*377*

为DateField列。

为什么我似乎要失去一毫秒？

sql sql-server

— sproketboy
source

我注意到了与“ 2008-12-31 23：59：59.999”之类的日期相同的错误

— Jhonny D. Cano -Leftware-'Apr

1

看看这个：SELECT CONVERT（DATETIME，'2008-12-31 23：59：59.999'）

— Jhonny D. Cano -Leftware-'Apr

有关更多详细信息，请参阅此问题

— John M Gant

95

SQL Server仅将时间存储到大约1/300秒。这些总是落在0、3和7毫秒上。例如以最小的增量从0开始计数：

00：00：00.000
00：00：00.003
00：00：00.007
00：00：00.010
00：00：00.013
...

如果您需要毫秒级的精度，那就没有令人愉快的方法了。我见过的最好的选择是将值存储在自定义数字字段中，并在每次获取值时对其进行重建，或者将其存储为已知格式的字符串。然后，出于速度考虑，您可以（可选）在原始日期类型中存储一个“近似”日期，但是它引入了概念上的复杂性，而这通常是不需要的。

— 那是啥
source

13

请务必阅读Rob Garrison关于TIME和DATETIME2的文章-这些类型的分辨率更高。

— 戴夫·马克

根据我到目前为止对Azure SQL的测试，我所有的DateTime字段都以毫秒为单位，分别是0、3和6

— Jason Dufair

41

SQL Server 2008具有更高的精度。datetime2类型将准确地存储以下值：2008-12-19 09：31：38.5670514（精度为100纳秒）。

参考：时间和日期时间2-探索SQL Server 2008的新日期/时间数据类型

— 罗伯·加里森
source

27

SQL Serverdatetime类型的分辨率只有1/300秒（约3.33毫秒），因此您可能会看到舍入错误。

请参阅MSDN Datetime SQL Server参考

— 彼得·M
source

6

SQL Server仅精确到1/300秒。它将数值四舍五入到最接近的1/300。

— 汤姆·H
source

感谢您的答复。让我感觉好些。我只需要调整单元测试。:)

— sproketboy

1

关闭，3/1000分辨率为000、003、006、009 ... 1/300分辨率为000、003、007、010 ...

— Eclipse

3

DATETIME没有无限的精度-您可能使用的值无法用可用位准确表示。

2

SQL Server将日期时间值存储为3毫秒的精度。（我听说过此消息，但找不到官方参考。）

— 公爵
source