DATETIME2(2)值会小于自身吗？SQL脚本异常问题咨询

AI 小北

2026-8-25

问题描述

我有一个分多步执行的SQL脚本，用于将数据导入表中并汇总执行情况，全程在单个事务内运行。目标表包含声明为[TimeLastSeen] DATETIME2(2)的列。脚本开头声明：

DECLARE @now DATETIME2(2) = GetDate();

并在脚本中统一使用该变量替代GetDate()，@now仅赋值一次且未被修改。

导入数据时，在大型MERGE语句中执行：

UPDATE ... SET [TimeLastSeen] = @now

随后通过以下语句检查本次导入中未被更新的记录：

INSERT INTO #MergeResult ([Action], [TargetId], [TargetBusinessName], [TargetLicenseNumber])
SELECT 'MISSED', [Id], [BusinessName], [LicenseNumber]
FROM [Providers]
WHERE [TimeLastSeen] < @now;

该脚本多次运行正常，但某次执行时，虽更新了所有记录，却报告所有导入行都被标记为“未更新”——即所有记录的[TimeLastSeen]都满足< @now，而@now是同一个值。重新运行同一导入文件时，脚本又恢复正常，没有记录匹配该条件。

想问：DATETIME2(2)类型的值会出现小于自身的情况吗？解决方案是改用更高精度的DATETIME2(6)，还是添加：

DECLARE @justBeforeNow DATETIME2(6) = DATEADD(millisecond, -1, @now);

并使用该值进行比较？

问题分析与解决方案

核心原因：隐式类型转换导致的精度差异

DATETIME2(2)类型的值不会直接小于自身，问题出在GetDate()的返回类型和隐式转换上：

GetDate()返回的是DATETIME类型，精度仅为1/300秒（约3.33毫秒），而DATETIME2(2)是精确到百分秒（10毫秒）的类型。
当你把DATETIME值赋值给DATETIME2(2)变量@now时，SQL Server会进行四舍五入截断；但后续执行比较[TimeLastSeen] < @now时，可能触发隐式类型转换——将DATETIME2(2)类型的列值和变量转换回DATETIME类型，这时候原本相等的DATETIME2(2)值，在转换为DATETIME后可能出现细微差异，导致错误的比较结果。

推荐解决方案

方案1：替换GetDate()为SYSDATETIME()

将@now的赋值语句改为：

DECLARE @now DATETIME2(2) = SYSDATETIME();

SYSDATETIME()返回DATETIME2(7)类型（高精度时间），赋值给DATETIME2(2)时的转换逻辑更直接，避免了DATETIME与DATETIME2之间的跨类型转换，从根源上消除隐式转换带来的精度问题。

方案2：统一使用更高精度的DATETIME2(6)

将目标表的[TimeLastSeen]列改为DATETIME2(6)，同时将@now声明为DATETIME2(6)：

DECLARE @now DATETIME2(6) = SYSDATETIME();

更高的精度不仅能避免转换问题，还能保留更精细的时间戳，适合需要精确时间记录的场景。

方案3：使用@justBeforeNow作为规避方案

如果暂时无法修改列类型或赋值逻辑，可以使用你提到的@justBeforeNow来规避比较时的精度问题：

DECLARE @justBeforeNow DATETIME2(2) = DATEADD(millisecond, -1, @now);

然后将比较条件改为：

WHERE [TimeLastSeen] <= @justBeforeNow;

这会确保只有真正早于@now的记录会被标记为"MISSED"，避免因转换误差导致的误判。但这只是临时规避，优先推荐前两种方案从根源解决问题。

内容的提问来源于stack exchange，提问作者Carl Raymond