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)更安全 - 如果要兼容多数据库，改用
order_time 这类表达式（MySQL）或<code>order_time （SQL Server），绕过<code>DATEDIFF本身
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()返回1 mon 3 days这种没法排序的字符串 - 别在WHERE里写
ship_time - order_time > '7 days'——虽然语法对，但隐式转换易出错，显式转成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：应用层拿到时间立刻
CONVERT_TZ(..., '+08:00', '+00:00')（MySQL）或AT TIME ZONE 'UTC'（SQL Server 2016+） - 查数据时别依赖数据库当前时区：SQL Server用
GETUTCDATE()而非GETDATE()，MySQL确认@@time_zone是'+00:00'而不是'SYSTEM' - 字段命名加后缀：比如
created_at_utc、shipped_at_local，强制提醒自己单位不一致
真正麻烦的不是怎么算差值，而是搞清每个时间字段背后代表的时区含义和业务语义。哪怕DATEDIFF语法全对，只要源头时间戳带有时区歧义，结果就不可信。
