TIMESTAMPDIFF(MINUTE, start_time, end_time) 返回整数分钟差，参数顺序颠倒会导致负值；单位须大写，支持DATETIME/TIMESTAMP/字符串；TIMEDIFF不适用数值计算；跨天跨年可靠，但需注意时区和索引优化。
MySQL里用TIMESTAMPDIFF算分钟差，参数顺序不能反
结果为负数？大概率是把开始时间和结束时间传反了。TIMESTAMPDIFF要求第一个参数是单位（如MINUTE），第二个是“较早时间”，第三个是“较晚时间”。传成TIMESTAMPDIFF(MINUTE, end_time, start_time)就会得到负值，而不是报错。
常见写法：
SELECT TIMESTAMPDIFF(MINUTE, '2024-05-01 10:00:00', '2024-05-01 10:35:20');
返回 35（不是 35.33，它只取整数部分，向下截断）。
- 单位必须大写：
MINUTE，不能写minute或minutes - 两个时间参数支持
DATETIME、TIMESTAMP、字符串（格式需为'YYYY-MM-DD HH:MM:SS'或兼容格式） - 如果字段是
DATE类型（无时分秒），会被自动补为00:00:00，可能造成意外偏差
和TIMESTAMPDIFF容易混淆的TIMEDIFF不适用分钟差场景
TIMEDIFF返回的是时间间隔类型（如 '00:35:20'），不是数值，不能直接用于计算或比较大小。想转成分钟还得再套一层 HOUR() 和 MINUTE() 提取并换算，非常麻烦且易出错。
错误示范：
SELECT TIMEDIFF('2024-05-01 10:35:20', '2024-05-01 10:00:00'); -- 返回 '00:35:20'，不是 35
正确做法就是坚持用 TIMESTAMPDIFF(MINUTE, ...)，一步到位。
-
TIMEDIFF适合做“时间点相减得持续时间”的展示，不适合参与数值运算 - 如果真要用
TIMEDIFF换算分钟，得写成HOUR(TIMEDIFF(...)) * 60 + MINUTE(TIMEDIFF(...))，性能差、可读性低、还可能因秒数进位出错
跨天、跨月甚至跨年的时间差，TIMESTAMPDIFF依然可靠
它按日历单位计算，不是简单转成秒再除。比如从 '2024-01-31 23:00:00' 到 '2024-02-01 01:00:00' 是 2 小时，TIMESTAMPDIFF(MINUTE, ...) 返回 120，没问题；但如果算月份差：TIMESTAMPDIFF(MONTH, '2024-01-31', '2024-02-01') 返回 1（因为跨了月），不是按天数比例折算。
- 对分钟级精度需求来说，只要时间字段带完整时分秒，跨天完全不影响准确性
- 注意时区：如果两个时间值没显式指定时区（如没用
CONVERT_TZ），MySQL 默认按会话时区解析，可能导致线上环境与本地开发结果不一致 - 如果时间来自不同系统（比如一个存 UTC，一个存本地时间），必须先统一时区再计算
在WHERE条件里用TIMESTAMPDIFF要小心隐式转换开销
如果写成 WHERE TIMESTAMPDIFF(MINUTE, create_time, NOW()) > 30，MySQL 无法使用 create_time 上的索引（因为对字段做了函数操作）。数据量一大，查询就变慢。
- 更高效写法是把函数移到右边：
WHERE create_time - 这样
create_time保持裸字段形式，能走索引 - 同理，避免在
ORDER BY或GROUP BY中对时间字段用TIMESTAMPDIFF，优先考虑预计算或加生成列
实际业务中，最常被忽略的是时区一致性与索引失效这两点——前者导致数据对不上，后者让查询越来越慢，但错误表现都不明显。
