TIMESTAMPDIFF 返回“完整间隔数”，非四舍五入值；如364天差返回0年，365天才返1；按日历边界计算，月末日期自动向下取整；索引失效需改写条件为字段 op 表达式；跨时区须显式转换至UTC。
为什么 TIMESTAMPDIFF 返回结果和手算不一致？
因为 TIMESTAMPDIFF 计算的是“完整间隔数”，不是四舍五入或截断后的近似值。比如两个日期相差 364 天，用 TIMESTAMPDIFF(YEAR, ...) 得到 0；相差 365 天才得 1。它不看小数部分，只看跨过了多少个完整的单位边界。
常见错误是误以为它类似 Excel 的 DATEDIF 或 Python 的 relativedelta —— 实际上它更接近“日历计数器”：只统计从起始时间到结束时间之间，目标单位（如年、月）的整数次变化次数。
- 单位必须用大写常量：
YEAR、MONTH、DAY、HOUR、MINUTE、SECOND - 参数顺序固定：
TIMESTAMPDIFF(unit, datetime_expr1, datetime_expr2)，结果 =datetime_expr2 - datetime_expr1 - 若
datetime_expr1 > datetime_expr2，结果为负数，不会报错
TIMESTAMPDIFF(MONTH, ...) 为什么有时“跳月”不按预期？
它按日历月计算：比较两个日期的年份差 ×12 + 月份差，再根据“是否已过当月对应日”微调。例如：
SELECT TIMESTAMPDIFF(MONTH, '2023-01-31', '2023-02-28'); -- 返回 0（2月28日还没到1月31日的“下个月”）
而：
SELECT TIMESTAMPDIFF(MONTH, '2023-01-28', '2023-02-28'); -- 返回 1
本质是 MySQL 内部把两个日期归一化到“同日”比较，遇到月末日期会自动向下取整（如 1月31日 → 1月30日），再做减法。
- 不要依赖它做“天数折算”：3个月 ≠ 90天，尤其跨闰年或大小月时
- 如果需要按实际天数估算月均值，先用
TIMESTAMPDIFF(DAY, ...)再除以 30.44 更稳妥 - 对账类场景建议统一用
DAY单位，避免月度逻辑歧义
在 WHERE 条件里用 TIMESTAMPDIFF 会导致索引失效吗？
会。只要字段被包裹在函数中，如 WHERE TIMESTAMPDIFF(DAY, created_at, NOW()) > 30，MySQL 无法直接使用 created_at 上的索引，必须全表扫描。
正确做法是把函数移到右侧，让左侧保持裸字段：
WHERE created_at < DATE_SUB(NOW(), INTERVAL 30 DAY)
这样优化器能走索引。同理适用于 DATE_ADD、DATE_SUB 等日期运算函数。
- 所有涉及索引字段的条件，优先考虑“字段 op 表达式”形式，而非“函数(字段) op 值”
-
INTERVAL支持复合单位：INTERVAL 1 YEAR 2 MONTH，但注意顺序不可颠倒 - 如果业务逻辑强制要算动态差值（如“最近N个月订单”），考虑加一个生成列 + 索引缓存结果
跨时区计算时 TIMESTAMPDIFF 怎么不出错？
它默认按会话时区解释输入值。如果你传入的字符串没带时区信息（如 '2023-05-01'），MySQL 会当作当前会话时区的时间处理；若字段是 TIMESTAMP 类型，则存储时已转为 UTC，读取时再转回会话时区——这会导致两次转换叠加，差值失真。
最稳的方式是统一转成 UTC 时间戳再算：
SELECT TIMESTAMPDIFF(HOUR,
CONVERT_TZ('2023-05-01 10:00:00', '+08:00', '+00:00'),
CONVERT_TZ('2023-05-01 15:00:00', '-05:00', '+00:00')
);- 永远显式指定输入时间的原始时区，别依赖系统默认
- 避免混用
DATETIME和TIMESTAMP字段参与同一计算：前者无时区含义，后者有隐式转换 - 生产环境建议把所有时间字段存为
TIMESTAMP，并在连接层设好time_zone='+00:00'
真正麻烦的不是函数怎么写，而是你是否清楚自己要的是“日历差”还是“物理时长差”。选错单位或忽略时区/月末规则，查出来的数字看起来对，其实已经偏了几天甚至几个月。
