datediff函数在mysql、sql server和postgresql中参数顺序、单位要求及存在性差异显著：mysql用datediff(end,start)，sql server需指定单位且为datediff(unit,start,end)，postgresql无此函数而用日期相减；同时需注意隐式截断时间部分、时区处理、业务天数计算及null值影响。
DATEDIFF 函数在不同数据库里的参数顺序不一致
MySQL、SQL Server 和 PostgreSQL 对 DATEDIFF 的支持差异很大，甚至名字都不统一。MySQL 没有 DATEDIFF() 作为日期差函数（它用的是 DATEDIFF(end_date, start_date)），而 SQL Server 的 DATEDIFF(day, start_date, end_date) 要求显式指定单位且参数顺序相反。PostgreSQL 根本没有 DATEDIFF，得用 end_date - start_date 直接相减。
常见错误是把 MySQL 写法直接套到 SQL Server 上，结果算出负数或报错 Incorrect parameter count。
- MySQL：
DATEDIFF('2024-05-10', '2024-05-01')→ 返回9 - SQL Server：
DATEDIFF(day, '2024-05-01', '2024-05-10')→ 返回9 - PostgreSQL：直接写
'2024-05-10'::date - '2024-05-01'::date→ 返回9
别忽略日期类型隐式转换导致的精度丢失
如果字段是 DATETIME 或 TIMESTAMP 类型，DATEDIFF 在大多数数据库中只比较「日期部分」，自动截断时间。比如 '2024-05-01 23:59:59' 和 '2024-05-02 00:00:01' 用 DATEDIFF 算出来是 1 天，但实际只差 2 秒。
需要精确到小时/分钟时，不能依赖 DATEDIFF，得换方式：
- SQL Server：用
DATEDIFF(second, start, end) / 86400.0 - MySQL：用
TIMESTAMPDIFF(DAY, start, end)（注意不是DATEDIFF）更可控 - 若字段含时区（如
TIMESTAMP WITH TIME ZONE），先用AT TIME ZONE或CONVERT_TZ对齐再算
计算“业务天数”时 DATEDIFF 不够用
DATEDIFF 算的是日历天数，不区分工作日、节假日或周末。很多场景（比如 SLA 计算、合同履约期）要排除周六日和法定假日。
这种需求没法靠单个 DATEDIFF 解决，必须配合其他逻辑：
- 建一张
calendar表，标记每天是否为工作日（is_workday布尔字段） - 用子查询或 CTE 统计两个日期间满足
is_workday = true的记录数 - 避免用循环或 UDF，性能差；优先走 JOIN + COUNT(*)
例如 MySQL 中：
SELECT COUNT(*) FROM calendar WHERE date_col BETWEEN '2024-05-01' AND '2024-05-10' AND is_workday = 1;
NULL 值会让 DATEDIFF 返回 NULL，而不是 0
只要任意一个参数是 NULL，DATEDIFF 结果就是 NULL，不会抛错也不会默认填充。线上数据常有缺失，直接用于报表或 WHERE 条件会导致整行被过滤或聚合异常。
务必提前处理：
- 用
COALESCE(start_date, '1970-01-01')填充默认值（注意选合理兜底日期） - WHERE 子句里加
start_date IS NOT NULL AND end_date IS NOT NULL - 在应用层做空值校验比在 SQL 里硬补更安全，尤其涉及业务语义时
最麻烦的是嵌套计算——比如 DATEDIFF(...) 作为 CASE WHEN 的分支结果，一旦某分支为 NULL，整个表达式可能意外中断。这种情况建议拆成独立字段或用 CTE 预处理。
