SQL如何计算两个日期差值？DATEDIFF函数在生产中的应用
在数据库开发中，计算两个日期的差值看似基础，实则暗藏玄机。不同数据库的实现细节差异，常常成为线上查询结果出错或性能瓶颈的根源。其中，MySQL的DATEDIFF(end_date, start_date)与SQL Server的DATEDIFF(datepart, start_date, end_date)在参数顺序和用法上就截然不同，而PostgreSQL则更倾向于直接用end_date - start_date来计算天数。跨数据库操作时，还需额外注意时区统一和业务天数的特殊处理。
MySQL和SQL Server的DATEDIFF参数顺序相反
一个常见的“坑”是，直接写DATEDIFF('2023-01-01', '2023-01-10')在不同的数据库里，结果可能就差了一个负号——这往往是线上数据核对翻车的最常见原因。核心区别在于：MySQL采用的是DATEDIFF(end_date, start_date)的顺序，而SQL Server则是DATEDIFF(datepart, start_date, end_date)。不仅如此，SQL Server还必须显式指定datepart参数，比如是计算‘day’还是‘month’。
那么，具体该如何规避呢？
- 迁移先检查：在进行跨数据库SQL脚本迁移前，第一件事就是检查
DATEDIFF的调用方式。如果没带datepart参数，那基本就是MySQL风格，直接搬到SQL Server上会报出"Incorrect syntax near ','"的错误。 - 显式优于隐式：在生产环境的脚本中，不要依赖任何默认单位。明确写出
DATEDIFF(day, order_time, ship_time)远比DATEDIFF(order_time, ship_time)来得安全可靠。 - 寻求兼容方案：如果代码需要兼容多种数据库，不妨换个思路，绕过
DATEDIFF函数本身。例如，在MySQL中使用order_time <= DATE_SUB(ship_time, INTERVAL 7 DAY)这样的表达式，而在SQL Server中则使用order_time <= DATEADD(day, -7, ship_time)。
PostgreSQL不用DATEDIFF，但日期相减更直观
PostgreSQL走了一条更简洁的路：它压根没有DATEDIFF这个函数。计算日期差？直接用减法end_date - start_date就行，结果直接返回天数整数，连函数调用都省了。不过，这里有个细节需要注意：如果操作的是两个TIMESTAMP类型，相减得到的是一个INTERVAL类型，这时就需要再用EXTRACT(DAY FROM ...)或AGE()函数进行进一步处理。
具体可以这样操作：
- 纯日期比较：对于
DATE类型，直接使用ship_date - order_date，结果是integer，可以无缝参与WHERE过滤或ORDER BY排序。 - 含时间戳的场景：需要精确到天数时，可以使用
EXTRACT(EPOCH FROM (ship_time - order_time)) / 86400来计算。这比用AGE()函数更稳妥，因为AGE()可能返回像‘1 mon 3 days’这样的字符串，不利于直接排序。 - 注意隐式转换：尽量避免在WHERE条件中直接写
ship_time - order_time > '7 days'。虽然语法可能正确，但隐式转换容易引发意外错误。更稳妥的做法是显式转换为INTERVAL类型，如INTERVAL '7 days'。
计算“业务天数”时DATEDIFF不够用
标准的DATEDIFF只计算日历上的连续天数，但实际业务需求往往更复杂，需要剔除周末、节假日，只计算“业务处理时长”。例如，客服工单的SLA要求5个“工作日”内响应，直接用DATEDIFF就会把中间的周六日也算进去，导致考核失真。
面对这类需求，可以分层次考虑解决方案：
- 简单场景（仅排除周末）：可以利用
WEEKDAY()（MySQL）或DATEPART(WEEKDAY, ...)（SQL Server）函数，配合条件语句来计数。但这种方法在大数据量表上性能较差，需谨慎使用。 - 中等规模数据：一个更优雅的方案是预先建立一张
calendar维度表，包含date、is_workday、holiday_name等字段。查询时通过JOIN关联，然后用SUM(is_workday)来快速统计有效工作日。 - 高频复杂查询：对于性能要求极高的场景，可以考虑将业务天数的计算逻辑下沉到应用层。数据库只负责存储原始时间戳，由应用程序来完成复杂的日期逻辑处理，从而减轻数据库的负担。
时区不一致会导致DATEDIFF结果漂移
这是一个非常隐蔽的问题：如果order_time存储的是UTC时间，而ship_time存储的是本地时区（例如Asia/Shanghai），那么直接相减可能会导致结果多算或少算整整一天。在跨时区的订单系统中，这类问题往往静默发生，直到财务对账时才会暴露差异。
要堵住这个漏洞，需要从存储和查询两个环节入手：
- 入库前统一时区：最佳实践是在数据入库前，就在应用层统一转换为UTC时间。例如，在MySQL中使用
CONVERT_TZ(..., '+08:00', '+00:00')，或在SQL Server 2016+中使用AT TIME ZONE 'UTC'。 - 查询时明确时区基准：避免依赖数据库的当前时区设置。在SQL Server中，使用
GETUTCDATE()而不是GETDATE()；在MySQL中，则要确认@@time_zone系统变量是‘+00:00’而非‘SYSTEM’。 - 字段命名显式化：通过字段命名来强制提醒时区信息，例如使用
created_at_utc、shipped_at_local这样的后缀，明确标识每个时间字段所代表的时区含义。
说到底，计算日期差的真正挑战，往往不在于语法本身，而在于厘清每个时间字段背后所代表的时区含义和具体的业务语义。即便DATEDIFF的语法用得完全正确，只要源头的时间戳存在时区歧义，最终的计算结果就依然不可信。
