datediff函数在mysql、sql server和postgresql中参数顺序、功能及精度差异显著：mysql用datediff(end,start)且截断时间；sql server用datediff(day,start,end)仅计日期差；postgresql无该函数，需用日期相减或extract。
DATEDIFF 函数在不同数据库里参数顺序不一致
MySQL、SQL Server 和 PostgreSQL 对 DATEDIFF 的支持差异很大，甚至名字都不统一。MySQL 没有 DATEDIFF() 接收三个参数的用法；SQL Server 的 DATEDIFF(day, start, end) 是「按日历日差计算」，但会忽略时间部分；PostgreSQL 根本没有 DATEDIFF，得用 end - start（返回 interval）再转成天数。
实操建议：
- SQL Server：用
DATEDIFF(day, @start, @end)，注意它只看日期部分，'2024-01-01 23:59'和'2024-01-02 00:01'算作 1 天，不是按小时进位 - MySQL：直接用
DATEDIFF(end_date, start_date)，两个参数，顺序是「后减前」，且自动截断时间部分 - PostgreSQL：写
(end_time::date - start_time::date)，或更精确地用EXTRACT(EPOCH FROM (end_time - start_time)) / 86400保留小数
想算“满24小时才算一天”就得绕开 DATEDIFF
很多业务场景要的是「真实经过时间」，比如会员有效期、SLA 响应时长，这时候 DATEDIFF 的“舍去时间部分”逻辑反而会出错。
常见错误现象：用户 1 月 1 日 20:00 注册，到 1 月 2 日 19:00 只过 23 小时，但 DATEDIFF 返回 1，误判为已满 1 天。
实操建议：
- SQL Server：改用
DATEDIFF(second, start, end) / 86400.0，强制按秒算再转天，结果带小数 - MySQL：用
TIMESTAMPDIFF(DAY, start_dt, end_dt)还是整数；真要精度，得用TIMESTAMPDIFF(SECOND, start_dt, end_dt) / 86400.0 - 避免用
ROUND()直接取整——可能把 0.99 天（23.76 小时）四舍五入成 1 天，业务上未必合理
跨时区计算必须先统一时区再算差
如果字段存的是 TIMESTAMP WITH TIME ZONE（如 PostgreSQL）或 datetimeoffset（SQL Server），直接套用 DATEDIFF 会因时区偏移导致结果偏差。例如 UTC 时间 2024-01-01 00:00 和北京时间 2024-01-01 08:00，在未转换前相减可能得 0 天，其实物理时间差是 8 小时。
实操建议：
- SQL Server：用
AT TIME ZONE转成统一时区，如start_dt AT TIME ZONE 'UTC' AT TIME ZONE 'China Standard Time' - PostgreSQL：用
start_dt AT TIME ZONE 'UTC'强制转成 UTC 时间戳再相减 - MySQL 不原生支持时区转换函数，推荐在应用层处理，或升级到 8.0+ 后用
CONVERT_TZ()
性能敏感场景慎用函数包裹日期字段
在 WHERE 条件中对日期字段用 DATEDIFF（如 DATEDIFF(day, create_time, GETDATE()) > 30），会导致索引失效，尤其在大表上扫描极慢。
实操建议：
- 把函数移到右边常量侧：改写为
create_time （SQL Server）或 <code>create_time （MySQL） - 确保
create_time列上有索引，且类型是DATETIME或TIMESTAMP，别用字符串存日期 - 如果必须按“距今天 N 天”动态过滤，考虑加一个计算列并建索引（如 SQL Server 的 persisted computed column）
真正容易被忽略的是：业务定义的“一天”到底指日历日、自然日还是 24 小时周期。没对齐这个前提，再准的 DATEDIFF 结果都可能是错的。
