这条SQL语句的意图是什么？DATEADD日期处理逻辑及替换可行性疑问

核心差异点 #

你认为可以直接替换的逻辑在绝大多数常规场景下是成立的，两者唯一的区别是原SQL中DATEADD(minute, -10, GETDATE())的设计，是专门用于处理午夜前后10分钟的边界业务规则。

原SQL运行逻辑拆解 #

我们逐段拆解执行步骤：

• 第一步DATEADD(minute, -10, GETDATE())：将当前系统时间往前偏移10分钟
• 第二步DATEDIFF(dd, 0, 偏移后的时间)：计算偏移后时间与SQL Server默认零日期（1900-01-01）的整数天数差，计算时会自动丢弃时分秒部分
• 第三步DATEADD(dd, 天数差, 0)：把计算得到的整数天数加回到零日期，最终得到对应日期的00:00:00时间点，返回类型为datetime

特殊边界场景说明 #

举个实际例子就能明显看出差异：假设当前执行SQL的时间是2024-05-20 00:06:00（午夜刚过6分钟）

• 直接用CAST(GETDATE() AS Date)得到的结果是2024-05-20
• 用原SQL逻辑执行的话，先减10分钟得到2024-05-19 23:56:00，最终返回的日期是2024-05-19

这种设计通常是为了匹配特定的业务规则：比如每日数据切分时间点是前一天的23:50，或者这段SQL的定时调度任务固定在午夜0点到0点10分之间执行，业务上要求取的是前一天的日期而不是刚到来的当天日期。

替换的可行性判断 #

如果你的业务不需要处理上述10分钟的临界规则，或者这段SQL永远不会在午夜0点到0点10分的区间执行，完全可以用CAST(GETDATE() AS Date)替换。后者写法更简洁易读，执行性能和原写法没有差异。
另外补充说明：原SQL中用DATEADD+DATEDIFF组合取日期零点的写法是SQL Server 2008版本之前的通用写法，当时还没有独立的Date数据类型，无法直接通过Cast截断时间部分，所以老代码中这类写法很常见。

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