为什么SQL Server丢失了毫秒？
我有一个这样的表结构：
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 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
…
如果你需要毫秒的准确度，那么没有什么好的方法。 我见过的最好的select是将值存储在自定义数字字段中，并在每次获取值时将其重新构build，或者将其存储为已知格式的string。 然后，您可以（可选）为了速度而在本机datetypes中存储“近似”date，但是它引入了通常不需要的概念复杂性。
SQL Server 2008有更多的精度可用。 datetime2types将准确地存储这样的值：2008-12-19 09：31：38.5670514（精确到100纳秒）。
参考： time和datetime2 – 探索SQL Server 2008的新date/时间数据types
SQL Server datetimetypes仅具有1/300秒（〜3.33̅ms）的分辨率，因此您可能会看到舍入错误。
请参阅MSDNdate时间SQL Server参考
SQL Server只能精确到1/300秒。 它会将值舍入到最接近的1/300。
DATETIME没有无限精度 – 您可能正在使用无法用可用位精确表示的值。
我听说，但找不到官方的参考，SQL Server存储date时间值的精度为3毫秒。
