MySQL不支持DATEDIFF分钟单位，需用TIMESTAMPDIFF(MINUTE,start,end)；SQL Server的DATEDIFF(minute,start,end)计算边界跨越而非精确分钟；PostgreSQL不用DATEDIFF而用EXTRACT或减法。
DATEDIFF 函数的 minute 参数在不同数据库中表现不一致
MySQL、SQL Server、PostgreSQL 对 DATEDIFF 的支持差异很大——MySQL 根本没有 DATEDIFF 的分钟单位，它的 DATEDIFF() 只返回天数；SQL Server 支持 DATEDIFF(minute, ...)，但参数顺序是 DATEDIFF(unit, start, end)；PostgreSQL 则压根不用 DATEDIFF，而是用 EXTRACT 或减法运算。直接套用“DATEDIFF(minute, a, b)”在 MySQL 里会报错或结果为 0。
MySQL 中正确计算分钟差的三种方式
MySQL 必须绕过 DATEDIFF，改用时间戳转换或时间函数组合：
-
TIMESTAMPDIFF(MINUTE, start_time, end_time)是最推荐的方式，单位明确、语义清晰、自动处理时区和日期边界 -
TIMESTAMPDIFF的单位参数必须是全小写（如MINUTE），大写或混合大小写在某些版本会失败 - 用
UNIX_TIMESTAMP(end_time) - UNIX_TIMESTAMP(start_time)再除以 60 也可行，但要注意：若时间跨夏令时或存在闰秒，结果可能偏差；且UNIX_TIMESTAMP()对NULL返回 0，容易掩盖空值问题 - 如果字段是
DATETIME但只存了日期（无时分秒），TIMESTAMPDIFF仍能算出 0 分钟，而手动减法可能因隐式转换出错
SQL Server 中 DATEDIFF(minute, ...) 的陷阱
SQL Server 的 DATEDIFF(minute, start, end) 看似简单，但实际行为常被误解：
- 它计算的是两个时间在“分钟刻度”上的边界跨越次数，不是精确的分钟数。例如
DATEDIFF(minute, '2024-01-01 10:59:59', '2024-01-01 11:00:00')返回1，尽管只差 1 秒 - 如果需要真正的小数分钟（如 1.5 分钟），得改用
DATEDIFF(second, start, end) / 60.0 - 注意参数顺序：
start在前、end在后；反着写会导致负值，且不易排查 - 当
start或end为NULL时，整个表达式返回NULL，不会报错，但可能让聚合结果意外丢失
跨数据库兼容写法建议
如果 SQL 需要同时跑在 MySQL 和 SQL Server 上（比如 ORM 动态生成），硬写 DATEDIFF 或 TIMESTAMPDIFF 都不可行。更稳妥的做法是：
- 在应用层统一做时间差计算，把时间字段读成
datetime对象再相减，避免数据库函数差异 - 若必须在 SQL 层处理，优先用标准 SQL 的
end_time - start_time（PostgreSQL 支持，SQL Server 2016+ 支持，MySQL 8.0+ 在某些模式下也支持），再配合EXTRACT(EPOCH FROM ...)或乘法换算 - 别依赖函数名相似就认为行为一致——
DATEDIFF在 SQL Server 和 Access 里也不同，Access 不支持minute单位
分钟级时间差看着简单，但数据库对“时间跨度”的定义根本不在一个逻辑层上。写之前先确认目标数据库版本和 NULL 处理策略，比调通第一行代码更重要。
