sql datediff参数顺序因数据库而异：sql server为datediff(unit,start,end)，mysql为datediff(end,start)，postgresql和sqlite不支持该函数；计算结果为日历天数，非工作日；需确保日期类型合法且避免隐式转换。
SQL DATEDIFF 函数的参数顺序不能颠倒
DATEDIFF 在不同数据库中的参数顺序不一致，这是最常踩的坑。SQL Server 和 Azure SQL 要求 DATEDIFF(day, start_date, end_date)，而 MySQL 的 DATEDIFF(end_date, start_date) 是反过来的——它只接受两个日期参数，且固定为「前者减后者」。
PostgreSQL 没有 DATEDIFF，得用 end_date - start_date（返回整数天数）；SQLite 同样不支持 DATEDIFF，要用 julianday(end_date) - julianday(start_date)。
- SQL Server：必须写成
DATEDIFF(day, '2023-01-01', '2023-01-10')，结果是 9 - MySQL：写成
DATEDIFF('2023-01-10', '2023-01-01')才得 9；若反写会得到 -9 - 别硬套语法——先查你用的数据库文档，确认函数是否存在、参数是否带单位（如
day）、顺序是否可交换
日期字段类型不匹配会导致计算失败或隐式转换错误
如果参与计算的列是 datetime、timestamp 或字符串（如 '2023-01-01 14:30:00'），DATEDIFF 行为可能出人意料。SQL Server 会截断时间部分再算天数；MySQL 则严格按完整 datetime 相减，但字符串若格式不对（比如 '01/01/2023'），可能转成 0000-00-00 导致结果为 NULL 或异常大值。
- 确保两个输入都是合法日期类型，或显式用
CAST(... AS DATE)/DATE()提取日期部分 - 避免直接比较
varchar类型的“日期字符串”，尤其当存在不同格式（YYYY-MM-DDvsDD/MM/YYYY）时 - 在 SQL Server 中，
DATEDIFF(day, '2023-01-01', GETDATE())安全；但DATEDIFF(day, '01-01-2023', GETDATE())可能因语言设置失败
用 DATEDIFF 计算“业务天数”时它完全没用
DATEDIFF 算的是日历天数，不是工作日、也不是排除节假日的天数。如果你需要“两个订单之间隔了多少个工作日”，它一个字也帮不上忙——它不会跳过周末，更不认识春节调休。
- 想算工作日？得自己建日历表，或用递归 CTE +
DATEPART(weekday, ...)过滤 - 要排除法定假日？必须关联一张节假日表，再用
NOT EXISTS或左连接筛掉 - 别试图用
DATEDIFF加减法“估算”工作日（比如 ×0.7），误差会随跨度增大而失控
替代方案比硬啃 DATEDIFF 更可靠
与其纠结各数据库 DATEDIFF 的差异，不如用标准 SQL 的减法操作——只要数据库支持日期相减并返回整数（如 PostgreSQL、MySQL、SQLite），就更直观、更少歧义。
- PostgreSQL：
date_col2 - date_col1→ 直接得整数天数 - MySQL：
DATEDIFF(date_col2, date_col1)是唯一选择，但记住顺序 - SQL Server：除了
DATEDIFF，也可用DATEDIFF_BIG(day, ...)防溢出（超 24 年时） - 跨数据库项目？封装成视图或应用层计算，别让 SQL 语句直接暴露方言细节
真正麻烦的从来不是函数怎么写，而是日期字段里混着 NULL、时区偏移、夏令时切换点——这些不会报错，但会让结果差一两天，还很难复现。
