DATEDIFF 返回边界跨越次数而非精确差值，如分钟差2秒返回1；DATEADD在WHERE中导致索引失效。
DATEDIFF 和 DATEADD 是 SQL Server 中处理日期逻辑最常被误用的两个函数，尤其在存储过程中——它们本身不复杂，但组合使用时容易因单位语义、边界计数、索引失效和时区隐含转换翻车。
SQL Server 的 DATEDIFF 不是“精确差值”，而是“边界跨越次数”
比如 DATEDIFF(MINUTE, '2024-01-01 10:00:59', '2024-01-01 10:01:01') 返回 1，哪怕只差 2 秒。这是因为函数统计的是「从起始时间到结束时间之间，跨过了多少个分钟刻度」，不是真实耗时。
- 用
DAY单位时，'2024-01-01 23:59:59'到'2024-01-02 00:00:00'就算 1 天 - 用
MONTH单位时，'2024-12-31'到'2025-01-01'就算 1 个月，不管实际才过 1 天 - 想算真实秒数差，优先用
DATEDIFF(SECOND, start, end)；超 24 天可能溢出int，改用DATEDIFF_BIG(SECOND, start, end)
DATEADD 在 WHERE 条件里会彻底废掉索引
写成 WHERE DATEADD(day, 7, order_time) 看似清晰，但数据库无法对 <code>order_time 列直接走索引——函数作用于列，强制全表扫描。
- 正确写法是把函数挪到右边：
WHERE order_time - 如果要查“过去 7 天内创建的订单”，别写
DATEDIFF(day, order_time, GETDATE()) ，改用 <code>order_time >= DATEADD(day, -7, GETDATE()) - 涉及时区时，
GETDATE()是服务器本地时间，建议统一用SYSDATETIMEOFFSET()+AT TIME ZONE显式转换
存储过程里混用 DATEDIFF 和 DATEADD 容易漏掉 NULL 和类型隐式转换
字段是 DATETIME2，但传入参数是 VARCHAR，SQL Server 可能按默认格式（如 mdy）解析，导致 '01/02/2024' 被当成 1 月 2 日而非 2 月 1 日。
- 所有输入参数务必显式
CONVERT(DATE, @start_date, 120)或TRY_CONVERT，避免运行时报错或静默错误 - 参与计算的字段或变量为
NULL时，整个DATEDIFF结果为NULL，别忘了用ISNULL(@start_date, '1900-01-01')或COALESCE做兜底 - 不要依赖字符串拼接构造日期，例如
DATEADD(day, 1, @year + '-' + @month + '-01')—— 月份为'5'时会变成'2024-5-01'，某些兼容级别下解析失败
跨数据库移植时，DATEDIFF 和 DATEADD 几乎没法直接复用
MySQL 没有 DATEADD，用 DATE_ADD(NOW(), INTERVAL 7 DAY)；PostgreSQL 没有这两个函数，靠 NOW() + INTERVAL '7 days' 或 current_date - INTERVAL '30 days'。
- SQL Server 的
DATEDIFF(day, a, b)对应 MySQL 的DATEDIFF(b, a)，顺序相反 - 若存储过程需多库支持，建议把日期逻辑下沉到应用层，数据库只暴露原始时间戳字段
- 实在要兼容，可用视图封装：SQL Server 里建视图用
DATEDIFF，MySQL 里用DATEDIFF+ 字段重命名，但维护成本高
真正难的不是写出一个能跑的语句，而是确保它在千万级订单表上仍高效、在跨年跨月边界不出错、在参数传入异常时有明确反馈——这些细节藏在 DATEDIFF 和 DATEADD 的括号外面。
