datediff函数参数顺序因数据库而异：mysql为datediff(end_date, start_date)，sql server为datediff(day, start_date, end_date)，postgresql不支持该函数而用end_date::date - start_date::date。
SQL里DATEDIFF函数到底怎么用，参数顺序别搞反
绝大多数人第一次用 DATEDIFF 都栽在参数顺序上：它不是「结束减开始」，而是「后一个减前一个」。比如 DATEDIFF('2024-01-01', '2023-12-25') 返回 7，但写成 DATEDIFF('2023-12-25', '2024-01-01') 就是 -7。结果正负直接取决于你传参的先后，不是日期本身的早晚关系。
不同数据库对第一个参数的含义也不同：
- MySQL 和 PostgreSQL（用
AGE或-运算符）不支持标准DATEDIFF，得改用DATEDIFF(end_date, start_date)形式（MySQL）或end_date - start_date（PostgreSQL） - SQL Server 和 Azure SQL 要求第一个参数是日期单位，比如
DATEDIFF(day, '2023-12-25', '2024-01-01') - SQLite 没有
DATEDIFF，只能用julianday(end) - julianday(start)
MySQL中计算天数差的正确写法和常见报错
MySQL 的 DATEDIFF 只接受两个 DATE 或 DATETIME 类型参数，且**不接受单位参数**。写成 DATEDIFF(day, a, b) 会直接报错 ERROR 1582 (42000): Incorrect parameter count in the call to native function 'DATEDIFF'。
实操建议：
- 确保字段类型是
DATE、DATETIME或能被隐式转换的字符串（如'2023-12-25'） - 如果字段含时间部分（
DATETIME），DATEDIFF自动截断到日，不四舍五入也不进位 - 遇到
NULL值时整个结果为NULL，需要提前用COALESCE处理，例如：DATEDIFF(COALESCE(end_date, CURDATE()), start_date)
SQL Server中DATEDIFF容易被忽略的精度陷阱
SQL Server 的 DATEDIFF 是按「边界跨越次数」算的，不是严格的时间差。比如 DATEDIFF(day, '2023-01-01 23:59:59', '2023-01-02 00:00:01') 返回 1 —— 因为跨过了「1月2日」这个日边界，哪怕只差2秒。
这意味着：
- 用
day单位时，只要起止日期的DATE部分不同，就至少返回 1 - 想算真实小时级差值，得用
hour或second单位再换算，例如：DATEDIFF(second, start_dt, end_dt) / 86400.0 -
DATEDIFF不处理时区，所有输入都被当作本地时间处理；若字段存的是 UTC 时间，需先用AT TIME ZONE转换
跨数据库兼容的天数差替代方案
如果项目要同时支持 MySQL、PostgreSQL、SQL Server，硬写 DATEDIFF 很难统一。更稳妥的做法是靠数据库内置的时间运算符：
- PostgreSQL：
end_date::date - start_date::date（返回整数天数） - MySQL：
DATEDIFF(end_date, start_date)（唯一推荐方式） - SQL Server：
DATEDIFF(day, start_date, end_date)，但注意它和 MySQL 参数顺序相反 - 通用兜底（含 NULL 安全）：
COALESCE(DATEDIFF(end_date, start_date), 0)（MySQL）或COALESCE(end_date - start_date, 0)（PostgreSQL）
真正麻烦的不是语法，而是团队里有人查文档抄了 SQL Server 写法扔进 MySQL 环境跑——报错信息不会告诉你「你混了方言」，只会说参数不对。上线前务必确认目标数据库类型。
