<p>TIMESTAMPDIFF返回0或负数主要是参数顺序错误：它计算datetime_expr2 - datetime_expr1，第二个参数应为较早时间、第三个为较晚时间；若传反则结果为负，且单位须大写、参数不能为NULL。</p>
为什么 TIMESTAMPDIFF 返回 0 或负数？
常见原因是参数顺序写反了：TIMESTAMPDIFF 要求第一个参数是单位（如 SECOND、DAY），第二个是**结束时间**，第三个是**开始时间**——不是“起始→结束”，而是“结束→开始”。写成 TIMESTAMPDIFF(DAY, '2024-01-01', '2023-12-25') 就会返回 -7，而不是 7。
容易踩的坑：
- 误把
TIMESTAMPDIFF当作DATEDIFF的增强版，其实它不接受字符串自动推断类型，两个时间参数必须是合法日期/时间值（DATETIME、TIMESTAMP或可转为时间的字符串） - 单位参数必须大写，
day或Day会报错：FUNCTION TIMESTAMPDIFF does not exist - 如果任一参数为
NULL，整个结果就是NULL，不会报错但容易被忽略
TIMESTAMPDIFF 支持哪些时间单位？
MySQL 8.0+ 支持全部 13 种单位，按粒度从大到小排列： YEAR、QUARTER、MONTH、WEEK、DAY、HOUR、MINUTE、SECOND、MICROSECOND、YEAR_MONTH、DAY_HOUR、DAY_MINUTE、DAY_SECOND。其中后三个是复合单位，比如 TIMESTAMPDIFF(DAY_SECOND, '2024-01-01 12:30:45', '2024-01-02 14:35:50') 返回的是「总秒数」，不是分段结果。
注意：
-
YEAR只看年份部分，TIMESTAMPDIFF(YEAR, '2023-12-31', '2024-01-01')返回 1，不考虑是否跨年满 365 天 -
QUARTER按日历季度算（1–3 月为 Q1），不是简单除以 3 - 复合单位如
DAY_HOUR实际返回的是「(天数 × 24) + 小时数」，不是结构化结果
在 WHERE 条件里用 TIMESTAMPDIFF 容易慢吗？
会。因为 TIMESTAMPDIFF 是函数，对字段施加函数会导致索引失效。比如 WHERE TIMESTAMPDIFF(HOUR, created_at, NOW()) > 24，即使 created_at 有索引，也会全表扫描。
更高效的做法是把函数移到右边：
WHERE created_at < DATE_SUB(NOW(), INTERVAL 24 HOUR)
这样优化器能走索引。同理，想查“过去 7 天的数据”，别写 TIMESTAMPDIFF(DAY, created_at, CURDATE()) <= 7，而应写：
WHERE created_at >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
另外注意：NOW() 和 CURDATE() 在执行计划里是常量，而 SYSDATE() 是语句执行时刻值，可能影响缓存和复制一致性。
和 DATEDIFF、TIMEDIFF 有什么本质区别？
DATEDIFF 只支持 DATE 类型，返回整数天数，忽略时分秒；TIMEDIFF 只支持时间部分（TIME），返回 TIME 类型差值（如 '02:30:00'）；而 TIMESTAMPDIFF 是唯一能指定任意单位、且兼容 DATETIME/TIMESTAMP 全精度的函数。
典型误用场景：
- 想算两个时间点之间几小时几分，却用
DATEDIFF→ 结果永远是整数天，丢失精度 - 用
TIMEDIFF算跨日时间差 → 超过 24 小时会溢出或截断（如TIMEDIFF('2024-01-02 01:00:00', '2024-01-01 23:00:00')返回'02:00:00'，不是 26 小时） - 需要向下取整的小时数（比如“至少 3 小时”），直接用
TIMESTAMPDIFF(HOUR, a, b)即可，它本身就不带小数——这点和某些语言里diffInHours()默认四舍五入不同
复合单位看起来方便，但实际业务中很少真需要 DAY_SECOND 这种单一数值，多数时候是为避免多次调用函数做缓存，或者用于排序。真正要展示“X 天 Y 小时 Z 分钟”，得自己拆解计算，TIMESTAMPDIFF 不提供格式化能力。
