datediff函数在mysql、sql server和postgresql中语法差异大：mysql为datediff(end_date,start_date)，sql server为datediff(datepart,startdate,enddate)，postgresql不支持需用减法或age()；三者单位、精度、索引使用均不同。
DATEDIFF 函数在不同数据库中的语法差异
MySQL、SQL Server 和 PostgreSQL 都有类似功能，但函数名和参数顺序完全不同，直接照搬会报错。DATEDIFF 在 MySQL 中是 DATEDIFF(end_date, start_date)，而在 SQL Server 中是 DATEDIFF(datepart, startdate, enddate)，PostgreSQL 则根本不支持 DATEDIFF，得用减法或 AGE()。
常见错误现象：把 MySQL 写法复制到 SQL Server，结果报 Incorrect syntax near ','；或者在 PostgreSQL 里硬写 DATEDIFF，提示 function datediff(unknown, timestamp, timestamp) does not exist。
- MySQL：只支持日期级差值（天），
DATEDIFF('2024-05-10', '2024-05-01')返回9 - SQL Server：必须指定单位，
DATEDIFF(day, '2024-05-01', '2024-05-10')返回9；DATEDIFF(hour, ...)才能算小时差 - PostgreSQL：用
end_time - start_time得到 interval，再提取天数：EXTRACT(day FROM (end_time - start_time))
计算时间差时容易忽略的精度问题
单纯用 DATEDIFF 算“天数”，会截断时间部分。比如 SQL Server 中 DATEDIFF(day, '2024-05-01 23:59', '2024-05-02 00:01') 返回 1，但实际只差 2 分钟——因为它是按日历日跳变点计算的，不是真正的时间跨度。
如果你需要精确到秒或小时，不能只依赖 day 单位：
- SQL Server：优先用
DATEDIFF(second, start, end)，再除以 3600.0 转小时（注意加小数点避免整除） - MySQL：用
TIMESTAMPDIFF更稳妥，例如TIMESTAMPDIFF(HOUR, start_time, end_time)，它会考虑完整时间戳 - 所有数据库中，字段类型必须是
DATETIME或TIMESTAMP，如果存的是字符串（如'2024-05-01'），先用STR_TO_DATE或CAST转换，否则结果不可靠
WHERE 条件中用 DATEDIFF 过滤数据的性能隐患
在 WHERE 子句里写 DATEDIFF(day, created_at, GETDATE()) > 30，会导致 created_at 字段无法使用索引——因为对列做了函数运算。执行计划里常看到 Index Scan 而不是 Index Seek，大数据量时慢得明显。
正确做法是把函数移到右边，让左边保持原始字段：
- SQL Server：
created_at - MySQL：
created_at - 这样
created_at可走索引，查询效率提升显著
跨时区时间差计算必须先统一时区
如果两个时间字段来自不同时区（比如一个存 UTC，一个存本地时间），直接算 DATEDIFF 得到的数值毫无业务意义。例如 UTC 时间 '2024-05-01 10:00' 和北京时间 '2024-05-01 18:00'，差值是 8 小时，但 DATEDIFF(hour, ...) 会当成同一时区算出 8，掩盖了本质是同一时刻。
处理方式取决于数据库能力：
- PostgreSQL：用
AT TIME ZONE标准化，如created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai' - MySQL 8.0+：用
CONVERT_TZ(created_at, '+00:00', '+08:00') - SQL Server：需手动加减偏移，或升级到 2016+ 用
AT TIME ZONE
没做时区归一就直接算差值，结果可能看起来“对”，但逻辑上已经错了——这点在日志分析、订单履约等场景特别致命。
