DATEDIFF函数在不同数据库中参数顺序和语义差异显著：MySQL为DATEDIFF(end,start)仅支持天数；SQL Server为DATEDIFF(unit,start,end)，unit须为无引号标识符；PostgreSQL无此函数，需用日期减法或AGE()。
DATEDIFF 函数在不同数据库里参数顺序不一致
MySQL、SQL Server 和 PostgreSQL 对 DATEDIFF 的支持差异很大——MySQL 没有原生 DATEDIFF 函数（它用的是 DATEDIFF(date1, date2)，但只返回天数且 date1 - date2）；SQL Server 的 DATEDIFF 是 DATEDIFF(unit, start, end)；PostgreSQL 根本没有这个函数，得用减法或 AGE()。别直接套用别人代码，先查你用的数据库手册。
- SQL Server：
DATEDIFF(day, '2023-01-01', '2023-01-10')返回9 - MySQL：
DATEDIFF('2023-01-10', '2023-01-01')返回9（注意：第一个是结束日） - PostgreSQL：用
'2023-01-10'::date - '2023-01-01'::date得整数天数
单位参数写错会导致结果完全偏离预期
SQL Server 的 DATEDIFF 第一个参数是时间单位，不是字符串字面量——必须用预定义标识符，比如 day、month、year，不能写成 'day'（带引号就报错），也不能拼错成 days 或 dd（部分版本虽兼容 dd，但不可靠）。
- ✅ 正确：
DATEDIFF(month, '2023-01-31', '2023-02-01')返回1（跨月即算 1，不管天数差多少） - ❌ 错误：
DATEDIFF('month', ...)→ 报错：“‘month’ is not a recognized table hints option” - ⚠️ 注意：
DATEDIFF算的是“边界跨越数”，不是精确时长。比如DATEDIFF(year, '2023-12-31', '2024-01-01')返回1，哪怕只差 1 天
日期字段类型不匹配会静默截断或报错
如果传给 DATEDIFF 的列是 DATETIME 或 TIMESTAMP，而你只关心日期部分，SQL Server 会保留时间参与计算（比如 '2023-01-01 23:59:59' 和 '2023-01-02 00:00:01' 在 day 单位下仍算 1 天）；但若一列是 DATE、另一列是 VARCHAR，SQL Server 可能尝试隐式转换失败，MySQL 则可能转成 0000-00-00 导致结果为 NULL 或异常大值。
- 安全做法：显式转换，如
DATEDIFF(day, CAST(start_date AS DATE), CAST(end_date AS DATE)) - 排查技巧：单独 SELECT 两列看实际值，尤其留意
NULL、空字符串、非法格式（如'2023/13/01'） - 索引影响：对列用
CAST(... AS DATE)通常无法走索引，大数据量时考虑提前物化日期字段
想算工作日或排除节假日？DATEDIFF 不行，得另写逻辑
DATEDIFF 只认日历天，不识别周一到周五，也不管是否国庆调休。硬要用它算“上班天数”，结果一定错——比如 DATEDIFF(day, '2023-10-01', '2023-10-07') 返回 6，但实际工作日是 0 天。
- 可行替代：用日历表（calendar table）LEFT JOIN 过滤
is_workday = 1后 COUNT - 简化方案：应用层处理（Python/Java 先生成日期序列，再用
datetime.weekday()过滤） - 警告：网上搜到的“用
DATEDIFF加减2 * DATEDIFF(week, ...)”之类公式，在跨年、闰年、月初月末边界极易出错，别抄
实际用的时候，先 SELECT @@VERSION 或查文档确认数据库类型，再决定用哪个函数、怎么写参数。最常被忽略的是单位语义（“跨了多少个单位” vs “相差多少单位”）和隐式类型转换——这两点一错，结果看着像对，其实已经偏了。
