DATEDIFF 应该是 SQL 里最常用也最容易被轻视的函数之一。很多开发者在项目初期用它算个日期差，感觉简单到不需要看文档——两个日期一减，天数出来了，完事。但等你真正处理过跨年数据、排查过慢查询、或者接过一个用了 Oracle 和 PostgreSQL 的遗留系统，就会发现这个函数在不同数据库里完全是不同的性格。我这几年前前后后踩过不少 DATEDIFF 的坑，也帮别人排查过不少相关的问题，今天就把这些经验系统性地整理出来，从语法差异到边界情况，从性能隐患到实际业务场景，一次讲透。
这篇文章适合刚接触 SQL 不久、想在日期计算上少走弯路的新手，也适合已经写了一段时间 SQL、但没来得及做系统性梳理的开发者。我会尽量把每个知识点都放到真实业务场景里说，而不是干巴巴地讲参数和返回值。
1. 先从基础说起：DATEDIFF 到底是什么
1.1 一个函数，两种完全不同的设计哲学
很多人的困惑其实从第一步就开始了：同样是 DATEDIFF，在 SQL Server 和 MySQL 里，参数的顺序竟然是反的。
-- SQL Server / T-SQL 的写法 DATEDIFF(datepart, startdate, enddate) -- MySQL 的写法 DATEDIFF(date1, date2)SQL Server 是“指定单位，然后给两个日期”，返回的是 enddate 减去 startdate 的结果，单位由 datepart 控制。MySQL 则简单粗暴，只有两个日期参数，单位固定是天，计算的是 date1 减去 date2 的天数差。
我刚从 MySQL 转去写 SQL Server 的时候，就因为参数顺序搞反出了好几次错。最气人的是这种错误不会立刻报错——你把两个日期参数换了个位置，SQL Server 照样正常运行，但结果变成了负数，或者刚好少了一天。所以第一件事就是搞清楚你正在用哪个数据库，然后把语法烂熟于心，不要凭记忆跨库写。
PostgreSQL 就更特殊了，它根本没有 DATEDIFF 这个函数。PostgreSQL 处理日期差的方式是直接做减法：
-- PostgreSQL 的写法 SELECT '2024-03-01'::DATE - '2024-02-01'::DATE; -- 结果是 29，是一个整数 SELECT '2024-03-01 12:00:00'::TIMESTAMP - '2024-02-01 10:00:00'::TIMESTAMP; -- 结果是 29 days 02:00:00，是一个 interval 类型Oracle 则走了另一条路，用两个日期直接相减，得到的是天数差（支持小数）。如果想要整数天数，需要配合 TRUNC 或者 ROUND 使用。
这些差异的存在其实揭示了一个核心问题：不同数据库在“日期差值”这个概念的建模上，根本没有统一标准。你写的每一段 DATEDIFF 代码，本质上都是在跟某个具体数据库的日期模型对话。
1.2 datepart 单位到底有哪些
如果你用 SQL Server，那你需要熟悉 datepart 参数的取值。我用得最多的是这几个：
| datepart | 缩写 | 返回结果说明 |
|---|---|---|
| year | yy, yyyy | 两个日期的年份差，注意不是“差多少年”，而是年份数字直接相减 |
| quarter | qq, q | 季度差 |
| month | mm, m | 月份差 |
| dayofyear | dy, y | 一年中的第几天之差 |
| day | dd, d | 天数差 |
| week | wk, ww | 周数差，按周日为一周起点计算 |
| hour | hh | 小时差 |
| minute | mi, n | 分钟差 |
| second | ss, s | 秒差 |
| millisecond | ms | 毫秒差 |
这里要特别提醒一个理解误区：DATEDIFF 返回的并不是“两个时间之间真正有多少个完整的周期”，而是“边界的跨越次数”。
这个说法有点绕，我用例子给你说明。假设我们要计算下面两个时间点之间的小时差：
- 开始时间：2024-01-01 00:00:00
- 结束时间：2024-01-01 01:59:00
实际间隔是 119 分钟，也就是 1.98 小时。但如果你执行 DATEDIFF(hour, start, end)，结果是多少？答案是 1。
为什么？因为 DATEDIFF 统计的是“时钟从 0 点走到 1 点的过程中，小时边界被跨过了几次”。0 点到 1 点之间只跨越了 1 次边界，也就是 1 这个刻度，所以返回 1，而不是 2 也不是四舍五入的 2。
再比如：
- 开始时间：2024-01-01 23:59:00
- 结束时间：2024-01-02 00:01:00
实际间隔是 2 分钟，但 DATEDIFF(hour, start, end) 返回的是 1。因为从 23 点进入 0 点（次日的 0 点）跨越了一次小时边界。
这个“边界计数”式的计算逻辑是 DATEDIFF 一切诡异行为的根源。很多开发者在算“有多少个小时”的时候直接拿 DATEDIFF(hour, ...) 来用，结果小数小时全部被丢弃，累积起来误差很大。如果你需要精确的小时差，应该用 DATEDIFF(second, ...) 除以 3600 保留小数，或者用 DATEDIFF(minute, ...) 除以 60。
同样，DATEDIFF(year, '2023-05-01', '2024-01-01') 的结果是 1，尽管实际间隔只有 8 个月不到，但因为年份边界从 2023 跨到了 2024，就被计为 1 年。这在某些年度报表统计里会产生误导。
1.3 返回类型：整数，以及那个让人头大的溢出问题
几乎在所有数据库里，DATEDIFF 返回的都是整数。SQL Server 的 DATEDIFF 返回 int 类型。这就引出了一个很经典的问题：如果两个日期相差太远，计算结果会溢出。
-- 这个会报错：The datediff function resulted in an overflow SELECT DATEDIFF(second, '1970-01-01', '2070-01-01');1970 年到 2070 年，一共 100 年，按秒算是 31,536,000 秒左右。int 类型的最大值约为 21.47 亿，看起来应该没超？实际上真的会溢出，因为 DATEDIFF(second, ...) 在 SQL Server 中计算的是纳秒边界转换为秒后的结果吗？不对，让我重新算一下。
100 年 × 365.25 天 × 86400 秒/天 = 3,155,760,000 秒（约 31.5 亿），这个值确实超过了 int 的最大值 2,147,483,647。所以确实会溢出。这也是为什么官方文档里专门有“对 DATEDIFF 返回值的精确性”的说明，并提供了 DATEDIFF_BIG 函数作为替代，返回 bigint 类型。
这种溢出问题在实战中最常见的触发场景是：用 DATEDIFF(second, ...) 来算两个时间戳之间相隔的秒数，然后用于生成某种唯一编号或者做令牌有效期判断。如果你只需要分钟级或天的粒度，就没必要选 smallest unit 的 SECOND，这也是一个性能优化点——单位越小，内部需要处理的数据精度越高，虽然计算量的差别在当前硬件条件下几乎可以忽略，但从规范性的角度来说，能用大单位就别用太小的单位。
2. 深入核心语义：日期差的计算逻辑和那些让你怀疑人生的边界
2.1 它是“拼接的日期”还是“连续的时间”
要真正理解 DATEDIFF，得先理解数据库里日期类型到底存的是什么。绝大多数数据库引擎里，日期类型是以特定格式存储的数字：SQL Server 的 datetime 类型内部是 8 字节结构，前 4 字节表示自 1900-01-01 以来的天数，后 4 字节表示当天的时钟刻度数。MySQL 的 DATETIME 本质上也是类似的数值结构。
这就意味着，无论你传入的是 ‘2024-01-01’ 这种纯日期，还是 ‘2024-01-01 08:30:00’ 这种带时间的完整值，引擎内部都会先把它解析成一个连续的时间线上的点，然后在这个时间线上做加减。
举个例子，SQL Server 中执行：
SELECT DATEDIFF(day, '2024-01-01 23:59:59', '2024-01-02 00:00:01');结果是多少？答案是 1，因为从 1月1日 的 23:59:59 到 1月2日 的 00:00:01，跨过了“日期从 1 变成 2”的边界，所以 day 的差值是 1，尽管实际物理间隔只有 2 秒。
这个特性在大多数业务场景下是合理的（比如我们通常认为 1月1日到1月2日算相隔 1 天，不管具体时刻），但在某些精度要求高的场景（例如套餐生效的时间精确到秒），你就需要格外小心——你面前这份结果，可能是“逻辑日差”，而不是“物理时差”。
我遇到过最典型的案例是签到业务的统计。当时需求是统计用户连续签到天数，我把每天的签到记录按天去重之后，用 DATEDIFF(day, pre_sign_date, current_sign_date) 来判断是否连续。如果差值等于 1 就说明连续，大于 1 就说明断了。这本身逻辑没问题，但有个用户反馈：他明明每天都签到了，系统却显示断签。后来排查发现，问题出在那个用户在特殊日期（比如跨月、跨年）有两条签到记录，而 DATEDIFF 计算时用了一条记录的两个时间点之间存在 1 天的边界跨越，但日期去重逻辑没处理干净，把同一天的记录当成了两天的记录，导致计算差值变成了 2。这里其实不是 DATEDIFF 的锅，是数据本身没清洗干净。但它提醒了我：DATEDIFF 只负责算数，不负责理解业务。你给它什么数据，它就给你什么结果，如果你的数据在业务逻辑上有歧义，函数本身绝不会好心帮你纠正。
2.2 跨月、跨年和闰年：计算逻辑为什么不用“每个月的实际天数”
很多新手会问一个很自然的问题：DATEDIFF(month, '2024-01-15', '2024-02-14') 等于多少？直觉来说，从 1月15日 到 2月14日，刚好一个月，对吧？那 DATEDIFF 的结果会是 1 个月吗？
答案是：等于 1。但原因跟你想象的“刚好满一个月”没有任何关系。它等于 1 是因为月份边界从 1 跨到了 2，哪怕只跨了一天。
再用一个极端点儿的例子：
SELECT DATEDIFF(month, '2024-01-31', '2024-02-01'); -- 结果是 1，尽管实际只差了 1 天（按钟表时间）同样的逻辑，DATEDIFF(year, '2024-12-31', '2025-01-01') 结果是 1 年，也就是跨年第一天就算一年。这些现象在第一次接触时非常反直觉，但一旦你接受了“DATEDIFF 数的是边界跨越次数，不是测物理长度”这个设定，一切都解释通了。
闰年的影响也属于这个范畴。DATEDIFF(year, '2024-02-29', '2028-02-29') 结果是 4，但在计算过程中，引擎不需要真的去数这 1461 天里有多少个闰日，它只是拿年份数值相减，2028 - 2024 = 4，完事。所以闰年对 DATEDIFF 本身的计算几乎不产生影响，真正需要操心闰年的是你自定义的一些日期推算逻辑，比如处理 2月29日 出生的人过生日这种需求。
2.3 参数顺序的陷阱：到底谁减谁
我知道前面提过参数顺序，但这个坑太常见了，值得单独拎出来再强调一遍。
SQL Server 的语法：
DATEDIFF(datepart, startdate, enddate)结果是 enddate - startdate。也就是说，如果你想算“到今天为止过了多少天”，那么 startdate=出生日期，enddate=今天。
MySQL 的语法：
DATEDIFF(date1, date2)结果是 date1 - date2。所以同样是“到今天过了多少天”，在 MySQL 里要写成 DATEDIFF(今天, 出生日期)。
我把这两种顺序记反过不止一次。后来我养成了一个习惯：不管是写新查询还是审查别人的代码，都先把“谁减谁”确认一遍。如果结果跟你的业务直觉相反，最常见的原因就是参数顺序写反了，而不是什么诡异的引擎 bug。
还有一种更隐蔽的参数陷阱：当你从某个 ORM 或者代码生成器里面拿 SQL，它会帮你自动拼接 DATEDIFF 的参数，但如果拼接逻辑在不同数据库间做了适配，你看到的参数顺序可能已经被改写了，这段 SQL 拿到别的库执行，结果就会出错。所以我建议在关键报表脚本里，对 DATEDIFF 统一加注释，标注清楚“这里是谁减谁，预期结果为正数”，方便后来人排查。
3. 实战场景：几个高频业务里的 DATEDIFF 用法和优化思路
理论说再多，都不如直接落到业务里来得实在。我挑了四个最常碰到 DATEDIFF 的业务场景，每个都给你一套可以直接用的方案。
3.1 用户年龄计算：别再直接DATEDIFF\一年了
最常见的错误写法是这样：
SELECT DATEDIFF(year, birthday, GETDATE()) AS age FROM users;前面说了，DATEDIFF(year, ...) 数的是年份边界的跨越次数。如果用户是 2024年12月31日 出生的，今天是 2025年1月1日，这个函数会返回 1 岁。但实际这个孩子出生才 1 天。你要是把这种逻辑用在用户实名认证、未成年人保护之类的场景，会出大问题。
一个比较稳妥的年龄计算方式，是先判断今年的生日过没过：
SELECT CASE WHEN DATEADD(year, DATEDIFF(year, birthday, GETDATE()), birthday) > GETDATE() THEN DATEDIFF(year, birthday, GETDATE()) - 1 ELSE DATEDIFF(year, birthday, GETDATE()) END AS age FROM users;这逻辑是：先拿 DATEDIFF(year, ...) 算出一个粗糙的年龄差值，然后用 DATEADD(year, 粗糙差值, birthday) 推算出“今年生日那天的日期”，如果这个日期比今天还大（说明生日还没到），就减一。
这个方案的好处是思路简单，而且所有计算都在数据库端完成，性能足够好。缺点是需要理解 DATEADD 的配合用法，很多人只熟悉 DATEDIFF，看到 DATEADD 就走了，这里特别说明一下它只是做简单日期偏移的。实际测试里，这个 CASE WHEN 的表达式在百万级用户表上执行，性能开销完全可接受，配合正确的索引策略根本不会拖慢查询。
MySQL 下对应的写法稍有不同，需要用到 DATE_ADD：
SELECT CASE WHEN DATE_ADD(birthday, INTERVAL TIMESTAMPDIFF(YEAR, birthday, CURDATE()) YEAR) > CURDATE() THEN TIMESTAMPDIFF(YEAR, birthday, CURDATE()) - 1 ELSE TIMESTAMPDIFF(YEAR, birthday, CURDATE()) END AS age FROM users;MySQL 中更常用的是 TIMESTAMPDIFF(YEAR, birthday, CURDATE())，它跟 SQL Server 的 DATEDIFF(year, ...) 行为几乎一致。注意 TIMESTAMPDIFF 的单位参数在第一个位置，别搞混。
3.2 订单超时判断：为什么你用 DATEDIFF 会把数据算没
电商系统里面特别常见的一个需求：找出创建超过 30 分钟还没支付的订单，然后自动关单。新手会这么写：
SELECT * FROM orders WHERE DATEDIFF(minute, created_at, GETDATE()) > 30;这个写法逻辑上没错，但性能上埋了一个大坑：你在 WHERE 条件里对 created_at 字段套了函数，这会导致这个字段的索引完全失效。数据库为了对每一行执行 DATEDIFF，必须全表扫描，没法直接利用 created_at 上的索引来过滤数据。当订单表只有几千条时没啥感觉，到了几十万、上百万量级，查询直接就崩了。
正确的写法是把计算挪到条件值的这一端，而不是字段那一端：
SELECT * FROM orders WHERE created_at < DATEADD(minute, -30, GETDATE());这个写法的思路是：“如果订单创建时间早于 30 分钟前，就说明超时了”，等价于“DATEDIFF 大于 30”。这样一来，created_at 字段是干净的，可以正常走索引。
这里补一句：为什么 DATEADD(minute, -30, GETDATE()) 这个写法在等值条件下也能走索引？因为 RDBMS 通常在解析 SQL 时会把这种常量表达式先计算出来，把 WHERE 变成created_at < '某个具体时间'，然后利用 B-tree 索引做范围扫描。而 DATEDIFF(分钟, created_at, 现在时间) 因为参数里有列引用，优化器很难把它翻转成对索引友好的形式。实测中同样的数据集，前者毫秒级返回，后者要扫几秒。这不是数据库没优化好，而是规则本来就是这样：让索引列独立出现在比较符的一侧，是所有 SQL 性能优化的铁律。
3.3 租期和会员有效期：首尾两天到底怎么算
做租赁系统或者会员系统的同学，一定会碰到这种问题：用户买了 7 天会员，从 2024年1月1日 开始，到期是哪天？
如果你的直觉是：DATEDIFF(day, '2024-01-01', '2024-01-07') 等于 6，所以还差一天，那你就得想清楚“第 7 天到期”的说法。
现实中，大多数系统是按“自然日”来算会员时长的。1月1日 开始算第 1 天，到 1月7日 的 23:59:59 结束。此时如果用 DATEDIFF(day, start, end) 去判断，拿到的 6 并不代表“少了 1 天”，而是边界跨越次数为 6。
处理这类业务时，我建议引入一个“闭开区间”的概念：
- 如果 1月1日 的 00:00:00 是生效时刻，那么 1月8日 的 00:00:00 是失效时刻，中间包含 7 个完整的自然日。
- SQL 里判断“当前时间是否在有效期内”：
now >= start_date AND now < end_date
如果数据库存的是开始日期和天数，到期日的计算直接用DATEADD(day, days, start_date)，不要自己去拼 DATEDIFF 来推。
再举个例子，有一回做了个图书借阅系统，借书当天算第 1 天，可借 15 天。开发在一开始写的是：
WHERE DATEDIFF(day, borrow_date, return_date) <= 15看起来没毛病，但用户在第 15 天当天还书时，DATEDIFF 算出来的值是 14，小于 15，判定为未超期，没问题。但到了第 16 天，返回值是 15，判定为超期——从业务上看其实也对，16 天超出 15 天额度了。可要是阅读题量一大，或者还书时间是 23:59:59，这条判断的边界就变得模糊了。后来我统一改成“应还日期”这个冗余字段，直接比较当前时间是否晚于应还日期，省掉了很多边界纠纷。这时候 DATEDIFF 不是不能用，而是它的“边界计数”语义在业务规则面前，不够直观。
3.4 连续签到与活跃度统计：DATEDIFF 配合窗口函数的经典组合
另一个我经常用 DATEDIFF 的场景是算用户连续活跃天数。比如某个内容社区，需要统计每天活跃用户里有多少人是“连续签到 7 天以上的”。
这类统计里，DATEDIFF 通常是配合 ROW_NUMBER 窗口函数用的。核心思路是“用日期减去行号，得到分组锚点”：
WITH signed_days AS ( SELECT user_id, sign_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY sign_date) AS rn FROM sign_records WHERE sign_date >= DATEADD(day, -7, GETDATE()) ) SELECT user_id, DATEADD(day, -rn, sign_date) AS group_start, COUNT(*) AS continuous_days FROM signed_days GROUP BY user_id, DATEADD(day, -rn, sign_date) HAVING COUNT(*) >= 7;原理很简单：如果用户连续签到，那么 sign_date 每天加一天，rn 每天也加一，两者相减（用 DATEADD 把 sign_date 往回调 rn 天）得到同一个 date 值。一旦断签了，DATEADD 的结果就会变，分组自然断裂。
这里 DATEDIFF 没用上，但其实前面判断“是否连续”时，你可以用 DATEDIFF(day, LAG(sign_date) OVER (...), sign_date) 来检查相邻两条记录是否间隔 1 天。不过窗口函数配 DATEADD 做分组是更优雅的做法，我对这个模式的评价是：它把日期计算和分组逻辑解耦了，可读性比 LAG 判断更好。
4. 工具选型和排查指南：常见报错、性能问题与实用技巧
4.1 那些年我们遇到过的 DATEDIFF 报错
把常见的报错信息和原因整理成一个速查表，开发排障的时候直接对号入座就行。
| 报错表现 | 可能原因 | 解决方法 |
|---|---|---|
| “DATEDIFF function resulted in an overflow” | 返回结果超出 int 范围，一般是 second 与远距离日期组合 | 改用 DATEDIFF_BIG，或调整单位为分钟/天 |
| “Invalid datepart argument” | datepart 参数写错，比如传了字符串 “daily” | 确认 datepart 的合法取值，见第一章的表格 |
| “Conversion failed when converting date and/or time from character string” | 日期参数是字符串，且格式不被当前会话识别 | 用 CONVERT 显式转换，或调整 SET DATEFORMAT / lc_time_names；存储层尽量用日期类型而非字符串 |
| “Cannot use datepart ‘n’ in datediff” | 某些方言不支持分钟缩写 | 确认当前数据库语法，SQL Server 里 mi/n 都是合法的，MySQL 则没有 DATEDIFF 分钟概念 |
| 返回负数 | 参数顺序写反了 | 确认 startdate 和 enddate 的位置语义 |
在实际排查时，有个技巧可以帮你快速定位是“语法问题”还是“数据问题”：挑一条可疑记录，单独把这两个源字段 SELECT 出来，先肉眼确认数据长什么样。很多时候报错不发生在语法解析阶段，而发生在数据读取阶段——比如有个字段里混入了几条 NULL 或 ‘0000-00-00’ 的脏数据，DATEDIFF 拿到 NULL 返回 NULL，一些聚合函数再处理时就会报错。这种情况你光看 SQL 是看不出来的，必须先查数据。
4.2 性能排查：当 DATEDIFF 出现在 JOIN 条件和子查询里
DATEDIFF 单独出现在 SELECT 子句里一般对性能影响不大。真正拖垮系统的是把 DATEDIFF 放在 JOIN 的 ON 子句或者大范围过滤条件里。
有一个我印象很深的例子：一张用户登录日志表和一张用户维度表做关联，开发为了“拿活跃用户列表”，写成了：
SELECT * FROM users u JOIN login_logs l ON DATEDIFF(day, l.login_time, GETDATE()) <= 30单看逻辑没错，但这会让数据库对每一行 login_logs 都执行一次 DATEDIFF 运算，并且完全放弃两个表之间任何可能的索引连接策略（因为连接键是一个表达式的结果，不是原始列）。如果把数据量放大到日增百万登录记录的场景，这条查询基本跑不完。
正确的改造思路：
- 先算出一个“30 天前的日期”常量，记为 cutoff_date = DATEADD(day, -30, GETDATE())。
- 把过滤条件改成
l.login_time >= cutoff_date。 - 再考虑 JOIN。
也就是说，永远记住一句话：DATEDIFF 可以用来算结果，但不要让它成为过滤或连接条件里的主导者。你需要的是把日期边界算好，然后直接用比较运算符。
另外，如果你在子查询里用了 DATEDIFF，并且这个子查询会被反复执行，可以考虑把它改成派生表缓存结果，或者用 WITH 公共表表达式。大多数优化器对 CTE 的重复引用处理得比较聪明，但如果你用的是很老的数据库版本，还是自己多留个心眼。
4.3 跨数据库迁移时的 DATEDIFF 兼容层
前面反复强调了不同数据库的 DATEDIFF 差异。如果你维护的是一个多数据库部署的系统（比如开发环境用 MySQL，生产环境用 SQL Server），最稳妥的做法是封装一层日期函数，不让业务代码直接依赖某个数据库特有的 DATEDIFF 语法。
我自己在项目中常用的一种思路是：定义一个统一的日期差函数接口，比如fn_date_diff(unit, start, end)，在数据库内部根据当前方言做转换：
- MySQL 里用
TIMESTAMPDIFF(unit, start, end)。 - SQL Server 里用
DATEDIFF(unit, start, end)。 - PostgreSQL 里用
EXTRACT(EPOCH FROM (end - start))配合单位换算。
当然，如果你的项目很简单，只有一种数据库，就没必要做这一层抽象。但如果你写过一段“同时跑 MySQL 和 PostgreSQL”的教训，就知道这层适配有多重要。我在一次把应用从 MySQL 迁到 PostgreSQL 的过程中，花了整整两天清理业务代码里各种 DATEDIFF 用法——MySQL 里顺手写一句 DATEDIFF(date1, date2)，到 PostgreSQL 里直接语法错误，全部得重写成 interval 减法。前期如果在 SQL 规范上多走一步，后面迁移能省一大笔时间。
4.4 单元测试视角：怎么给 DATEDIFF 逻辑写测试
很多开发只测业务代码，不测 SQL 脚本。但日期相关的逻辑恰恰是最容易出边界 Bug 的，强烈建议给 DATEDIFF 相关的查询写一套简单的回归测试。
覆盖的必要用例包括：
- 同一天内两个时刻的差值（应返回 0）
- 相邻两天凌晨的交界（验证边界跨越）
- 跨月、跨年、闰年 2月末 到 3月初
- 开始时间晚于结束时间（看返回值是否为负数，符合预期吗）
- NULL 参数（有些方言返回 NULL，有些直接报错）
- 时间部分不为零的日期，比如 23:59:59 到次日 00:00:01
这些用例写起来不复杂，但能帮你建立信心，尤其是当你改了一版 SQL 之后，跑一遍回归就能确认行为没有被无意改变。我在团队里推行的是“SQL 也要进测试库跑用例”的文化，一开始阻力不小，但连续几次靠测试用例抓出边界问题后，大家就接受了。
5. 两种特殊姿势：DATEDIFF 与 NULL 值、DATEDIFF 与字符串日期
5.1 NULL 值问题：为什么 DATEDIFF 偶尔会让你翻车
DATEDIFF 拿到 NULL 参数时，几乎所有数据库的处理方式都是返回 NULL。这在单行计算时没有风险，但一旦放进聚合或者 WHERE 比较里，NULL 的逻辑就会悄悄影响结果。
举个例子，统计“每个用户最近一次登录到现在相隔多少天”，你写了：
SELECT user_id, DATEDIFF(day, MAX(login_time), GETDATE()) AS days_since_last_login FROM login_logs GROUP BY user_id;如果某用户一条登录记录都没有，MAX(login_time) 是 NULL，那么 DATEDIFF 结果也是 NULL。应用层拿到 NULL 时，如果代码里直接做数值比较（比如days_since_last_login > 30），结果会变成“NULL > 30”，这在 SQL 和大多数编程语言里都是未知（false），于是这个用户会被静默漏掉。
正确做法是先用 COALESCE 或者条件聚合处理掉 NULL：
SELECT user_id, CASE WHEN MAX(login_time) IS NULL THEN NULL ELSE DATEDIFF(day, MAX(login_time), GETDATE()) END AS days_since_last_login FROM login_logs GROUP BY user_id;这个坑很多人都碰到过：明明用户很多，为什么统计出来的列表少了？后来一查，是 NULL 被静默过滤了。老实说，这个问题跟 DATEDIFF 没关系，是 SQL 的三值逻辑（TRUE/FALSE/UNKNOWN）在起作用。但因为它大量出现在 DATEDIFF 的使用场景里，我每次排查都离不开它。
5.2 字符串日期：隐式转换远比你想的危险
另一个高频翻车点是把日期字符串直接丢给 DATEDIFF。比如：
SELECT DATEDIFF(day, '2024-1-1', '2024.1.10');你的第一反应可能是：这格式这么乱，肯定报错吧？不一定。取决于数据库的解析规则和会话设置，这种字符串可能被成功解析成日期，也可能解析失败，甚至可能被解析成完全不同的时间点。
更危险的是隐式转换的不确定性。假设你把用户输入的日期存成了 VARCHAR，然后直接DATEDIFF(day, create_date, GETDATE())。有一天收到一批用户数据是'2024/1/1'，另一批是'2024-01-01'，还有几个是'20240101'，数据库可能会解析出不同的结果，而 SQL 本身又不会报错，只在最终结果上体现差异。这种“不报错但结果错”的 Bug，是最难排查的。
我的建议永远是多一步显式转换：
SELECT DATEDIFF(day, TRY_CONVERT(DATE, create_date, 120), GETDATE()) FROM ...SQL Server 的 TRY_CONVERT 在转换失败时返回 NULL，不会中断整个查询。这比直接 CONVERT 更稳妥，至少能让你通过 WHERE 过滤快速找出哪些记录格式异常。
6. 一些实操心得和最终建议
踩过这么多坑之后，关于 DATEDIFF 的使用，我总结出几条可以长期复用的经验。
第一，使用 DATEDIFF 前先确认两个语义：数据库方言的“谁减谁”和 datepart 的“边界计数”逻辑。写完之后，自己用一组包含边界值的数据快速验证，别只看正常情况。
第二，能用比较运算符解决的日期过滤，就不要用 DATEDIFF。比如判断某个时间是否超过 7 天，直接写created_at < DATEADD(day, -7, GETDATE())，既清晰又能走索引。
第三，要在多数据库环境里保持可迁移性，就封装一层自己的日期函数层。防的是未来迁移的麻烦。当时 MySQL 迁 PostgreSQL 的教训还历历在目，从那以后我们对 SQL 的跨库规范都严格了很多。
第四，不要在业务 SQL 里写那种一眼看不懂的嵌套 DATEDIFF，比如DATEDIFF(day, DATEDIFF(month, ...), ...)。SQL 的可读性本来就比编程语言低，如果又在关键报表里堆上这种“聪明代码”，等过了两个月，你自己回来看都会怀疑逻辑对不对。
最后分享一个我用了很久的小技巧：凡是跟“自然日”“边界”相关的统计需求，先在草稿纸上画一遍时间轴，把开始日期和结束日期标出来，再把“边界跨越次数”用竖线画出来，最后才写 SQL。这个习惯帮我少写了很多错代码，也让我在跟产品沟通需求时更准确地判断“为什么结果比预想的少了一天”。
如果这篇内容能帮你少踩一两个 DATEDIFF 的坑，我觉得这功夫就没白花。不管是你正在写第一版报表查询，还是在排查一个持续了很久的日期相关 bug，按上面这些思路捋一遍，基本都能找到问题的根源。祝各位写出的每个 DATEDIFF 都符合直觉，报表数字都对得上日期轴上的每一个刻度。
