Question

我想知道为什么你不能在{@ 1}}上使用DATEDIFF进行SubSelect。

MILLISECONDS

这导致（德语）：

Meldung 535：Die datediff-FunktionführtezueinemÜberlauf。 Die Anzahl von datepart-Werten，die zwei Datums- / Uhrzeitinstanzen trennen，istzugroß。

（英文对等）：

datediff函数导致溢出。分隔两个日期/时间实例的日期部分数量太大。尝试使用具有不太精确的日期部分的datediff。

如果我再次在SubSelect外使用相同的SELECT * FROM ( SELECT * FROM vrghmdemo.dbo.xrmQueues WHERE DATEDIFF(DAY, CreateDateTime, GETDATE()) < 2 ) sub WHERE DATEDIFF(MS, CreateDateTime, GETDATE()) < 500条件，则可以正常工作。

WHERE

为什么会这样？条件已在SubSelect中使用。

Answer 1

而不是以毫秒计算DATEDIFF，而是更改目标以进行比较：

select * from vrghmdemo.dbo.xrmQueues
where DATEADD(millisecond, -500, GetDate()) <= CreatedDateTime

还可以轻松地使用索引（在CreatedDateTime上，如果存在这样的索引）。

错误的原因是因为SQL Server可以自由地将计算移动到最有效计算的位置。在这种情况下，决定将外部DATEDIFF计算作为扫描基表，并在它考虑子查询中的谓词之前进行评估。

Answer 2

DATEDIFF返回INTEGER，它可以保存-2 ^ 31（-2,147,483,648）到2 ^ 31-1（2,147,483,647）的任何值。如果毫秒数超过此值，您将遇到溢出错误。

SQL Server 2016和Azure包含函数DATEDIFF_BIG，它返回BIGINT。这次你被限制在-2 ^ 63（-9,223,372,036,854,775,808）和2 ^ 63-1（9,223,372,036,854,775,807）之间的值。如果毫秒数超过这些限制，则无法使用此功能。

编辑：我已删除了以下部分。正如Damien_The_Unbeliever指出的那样，这是不正确的。

您的第二个查询通过仅确保带有a的记录来防止溢出计算2天的差异，这使您保持在INT限制范围内。

SubSelect上带有MILLISECONDS的SQL DATEDIFF

2 个答案: