我希望结果始终为1:
DECLARE @x datetime2
SELECT @x=GETDATE()
SELECT CASE WHEN @x>GETDATE() THEN 0 ELSE 1 END
但有时它是1,有时却是0。这是怎么可能的呢?
DECLARE @x datetime2
SELECT @x=GETDATE()
SELECT CASE WHEN @x>GETDATE() THEN 0 ELSE 1 END
但有时它是1,有时却是0。这是怎么可能的呢?
代码执行需要时间。有时,在第二行和第三行之间会发生一个时钟周期,但是有时(通常情况下)不会。在后一种情况(没有时钟周期),@x
仍然等于第三行中 GETDATE()
的值(而非大于该值),因此最终结果为 0
。起初让我惊讶的是你从来没有看到过 1
。当发生时钟周期时,@x
现在应该小于 第3行的新的 GETDATE()
值,但您将仍然看到 0
。
但是,运行此代码会更加清晰:
DECLARE @x datetime2
SELECT @x=GETDATE()
SELECT @x, GETDATE(), CASE WHEN @x>GETDATE() THEN 0 ELSE 1 END
现在我们可以更清晰地看到正在发生的事情。这是我机器上的一个示例结果:
2018-01-19 23:32:21.3833333 | 2018-01-19 23:32:21.383 | 1
啊啊啊...@x
是一个比旧的datetime
更精确的datetime2
。你可以在GETDATE()的文档中看到它返回的是datetime
而不是datetime2
。因此,在这两个值之间存在一些舍入误差。
对于0
的值,我运行了修改后的代码30或40次(按F5进行刷新),所有我看到的0
都是这样的:
2018-01-19 23:36:29.0366667 | 2018-01-19 23:36:29.037 | 0
第二列最后一位是7,而第一列有连续的6,并以圆形7结束,这是我的问题所在。
仍有一件事让我困惑。 GETDATE()
函数返回一个 datetime
值,但它以某种方式将 datetime2
精度分配给 @x
。 我只希望看到始终与原始 GETDATE()
结果匹配的额外零。
SYSDATETIME()
代替GETDATE()
将返回具有与@x
相同精度的DATETIME2
数据类型。 - marc_s