TIMESTAMPDIFF需显式指定全大写单位（YEAR/MONTH/DAY等），参数顺序为unit, datetime1, datetime2，结果为datetime2-datetime1，单位错误或顺序颠倒将导致报错或负值。
MySQL里用TIMESTAMPDIFF算两个日期差，单位选错会直接翻车
这个函数不是返回“天数”或“小时数”就完事了——它第一个参数是unit，必须显式指定，而且不支持字符串动态传入（比如'day'写成变量），写错大小写或拼错单位名（比如days多加个s）会报错FUNCTION TIMESTAMPDIFF does not exist。
常用合法单位只有这几个：YEAR、MONTH、DAY、HOUR、MINUTE、SECOND，全大写，不能带引号，也不能用小写。
-
TIMESTAMPDIFF(DAY, '2023-01-01', '2023-01-05')→ 返回4（注意：是整数差，不四舍五入） -
TIMESTAMPDIFF(MONTH, '2022-12-15', '2023-02-10')→ 返回1（只看年月，不看日，2022-12 到 2023-01 是1个月，到2023-02还是1个月） - 如果想按自然日算跨度，别用
MONTH，老实用DAY再除以30.4——TIMESTAMPDIFF本身不提供“平均月”或“工作日”模式
为什么TIMESTAMPDIFF结果有时是负数？顺序不能反
函数签名是TIMESTAMPDIFF(unit, datetime_expr1, datetime_expr2)，它算的是datetime_expr2 - datetime_expr1。很多人习惯“起始时间在前”，但这里恰恰相反：第二个参数才是被减数。
常见错误场景：
- 写成
TIMESTAMPDIFF(DAY, NOW(), create_time)，本意是“创建到现在几天了”，结果全为负数——因为create_time一般比NOW()早，得调换位置 - 和
DATEDIFF混淆：DATEDIFF(end, start)才是正向，而TIMESTAMPDIFF的参数顺序和它不一致 - 如果不确定谁大谁小，又不想处理负号，可以套一层
ABS()，但更推荐先理清业务逻辑再写表达式
跨时区或含时分秒的时间比较，要注意隐式类型转换
TIMESTAMPDIFF能处理DATETIME、TIMESTAMP、DATE甚至字符串（如'2023-01-01 12:30:45'），但MySQL会按规则做隐式转换——比如把DATE转成DATETIME时，默认补00:00:00，这可能导致“同一天但不同时间”的计算偏差。
- 例如：
TIMESTAMPDIFF(HOUR, '2023-01-01', '2023-01-02 01:00:00')→ 实际算的是'2023-01-01 00:00:00'到'2023-01-02 01:00:00'，结果是25，不是直觉上的24 - 如果字段是
DATE类型，又需要精确到小时，建议显式转成DATETIME：CAST(date_col AS DATETIME) - 时区问题：若列是
TIMESTAMP类型，值存的是UTC，读取时按session时区转出——TIMESTAMPDIFF内部运算仍基于存储值，所以跨时区对比前，确认两边是否已统一为同一时区时间（比如都转成UTC再算）
替代方案：什么时候不该硬用TIMESTAMPDIFF
它适合简单整数差计算，但遇到“是否满30天”“是否跨月”“排除周末”这类逻辑，硬凑TIMESTAMPDIFF反而绕路。
- 判断“是否超过30自然日”：用
DATE_ADD(create_time, INTERVAL 30 DAY) 比<code>TIMESTAMPDIFF(DAY, create_time, NOW()) > 30更直观且语义清晰 - 要算两个时间之间的工作日天数？
TIMESTAMPDIFF做不到，得结合WEEKDAY()或自定义函数 - 性能敏感场景：如果只是判断“是否在7天内”，用
create_time > DATE_SUB(NOW(), INTERVAL 7 DAY)比TIMESTAMPDIFF快——前者能走索引，后者无法利用索引
函数本身没问题，但容易让人忽略“日期比较的本质是范围判断”，而不是非得算出一个数字。
