DATEDIFF返回“少一天”是因为它统计边界跨越次数而非自然日差，如'2024-03-15'到'2024-03-15'返回0（未跨午夜），需加1才得包含首日的天数。
DATEDIFF 算出来“少一天”，大概率不是函数错了，而是你误把它当成了「结束日减开始日」的算术差，而它实际干的是「数边界跨了多少次」。
比如你查用户注册到今天的“存活天数”，期望 '2024-03-15' 到 '2024-03-15' 是 1 天，但 DATEDIFF(day, '2024-03-15', GETDATE()) 返回 0 —— 因为没跨任何午夜线。
为什么DATEDIFF(day, start, end)不等于(end - start)的自然天数？
DATEDIFF 的设计逻辑就是统计指定单位的“边界跨越次数”：
- 单位是
day：只看日期部分是否跨了午夜（即日期值是否变化），不关心时间点 -
DATEDIFF(day, '2024-03-15 23:59:59', '2024-03-16 00:00:01')→ 返回1（跨了一次午夜） -
DATEDIFF(day, '2024-03-15 00:00:00', '2024-03-15 23:59:59')→ 返回0（没跨午夜） - 它不处理“包含首尾”的业务语义，那是你应用层该决定的事
MySQL的DATEDIFF为什么看起来“多一天”或“少一天”？
MySQL 的 DATEDIFF 行为和 SQL Server 完全不同，但同样容易误导：
- 它只取日期部分，自动截断时间：
DATEDIFF('2024-03-16', '2024-03-15')=1 - 但参数顺序是
DATEDIFF(end_date, start_date)，如果传反了，结果直接变负：DATEDIFF('2024-03-15', '2024-03-16')=-1 - 常见错误：把带时间的字段（如
created_at）直接塞进去，以为能算小时级差异，结果全被截成日期比对 - 若你本意是“从创建那一刻起过了多少完整自然日”，
DATEDIFF就不是正确工具 —— 它连“半天”都不认
怎么得到真正的“自然天数”（含起始日）？
没有通用函数能自动满足所有“第几天”的业务定义，得按需调整：
- 若要“注册当天算第 1 天”，就用
DATEDIFF(day, start, end) + 1 - 若字段是
DATETIME且你想按 24 小时滚动计算，改用TIMESTAMPDIFF(DAY, start, end)（MySQL）或DATEDIFF_BIG(SECOND, start, end) / 3600.0 / 24（SQL Server） - PostgreSQL 没
DATEDIFF，直接(end::DATE - start::DATE) + 1更直观、可控 - 注意 NULL：任一参数为
NULL，结果就是NULL，别忘了用COALESCE或前置过滤
最容易被忽略的细节：跨时区和夏令时
如果你在用本地时间（比如 GETDATE()）和 UTC 存储的时间字段做 DATEDIFF，结果可能差整整一天：
-
DATEDIFF(day, '2024-03-10 01:00:00', '2024-03-10 03:00:00')在夏令时切换日凌晨，可能返回0或1，取决于系统如何解释那“消失的一小时” - 安全做法：统一转 UTC 再算，SQL Server 用
SWITCHOFFSET(col, '+00:00')，MySQL 用CONVERT_TZ(col, @@session.time_zone, '+00:00') - 别依赖数据库默认时区——它可能随服务器配置或连接会话悄悄改变
真正麻烦的从来不是函数不会算，而是你没意识到它根本不是为你设想的那个“算”法。
