timestampdiff计算秒数必须显式指定unit为second，即timestampdiff(second, start_time, end_time)；单位不能加引号或用函数形式，参数需为合法时间类型，结果向下取整且任一参数为null时返回null。
MySQL中TIMESTAMPDIFF计算秒数必须指定UNIT为SECOND
直接用 TIMESTAMPDIFF 算秒数，最容易错在第一个参数——它不是可选的，也不是默认秒，必须显式写 SECOND。写成 TIMESTAMPDIFF(SECOND, start_time, end_time) 才对；漏掉或写成 SECOND()、'second'（带引号）都会报错或返回 0。
常见错误现象：ERROR 1582 (42000): Incorrect parameter count in the call to native function 'TIMESTAMPDIFF'（参数个数错），或返回值恒为 0（单位字符串未被识别）。
-
TIMESTAMPDIFF第一个参数只接受无引号的单位标识符：如SECOND、MINUTE、HOUR、DAY等，不支持字符串字面量 - 后两个参数必须是合法时间类型：可以是
DATETIME、TIMESTAMP、DATE（自动补零时分秒），也支持字符串格式如'2024-01-01 12:30:45' - 结果是整数，向下取整——比如差 59.9 秒也返回 59，不会四舍五入
TIMESTAMPDIFF(SECOND, ...) 和 UNIX_TIMESTAMP(...) 减法的区别
有人会用 UNIX_TIMESTAMP(end_time) - UNIX_TIMESTAMP(start_time) 替代，看起来更直觉。但二者行为不同：前者严格按日历时间差计算（考虑闰秒、夏令时切换等系统级影响极小，但语义上是“时钟走过多少秒”），后者本质是转成 UTC 秒数再相减，更接近“绝对时间戳差”。实际项目中差异极少，但若涉及跨时区或历史日期（如 1970 年前），UNIX_TIMESTAMP 可能返回 NULL 或 0，而 TIMESTAMPDIFF 在有效范围内更稳定。
-
TIMESTAMPDIFF支持DATE类型输入，自动转为当天 00:00:00；UNIX_TIMESTAMP对纯DATE也有效，但逻辑不如前者清晰 - 性能上无显著差异，两者都是内置函数，执行很快
- 如果字段是
TIMESTAMP且含时区信息，TIMESTAMPDIFF在连接时区设置下仍按会话时区解释时间，需确认time_zone设置是否符合预期
注意字段类型和NULL值导致的静默失败
当参与计算的任一字段为 NULL，整个 TIMESTAMPDIFF 表达式结果就是 NULL，不会报错，容易被忽略。尤其在 JOIN 或 WHERE 中用于过滤时，可能让本该命中的行消失。
- 务必提前用
IS NOT NULL过滤，或用COALESCE提供默认值，例如：TIMESTAMPDIFF(SECOND, COALESCE(t1.created_at, NOW()), t1.updated_at) - 如果字段是
VARCHAR存时间（如'2024/01/01 12:30:45'），TIMESTAMPDIFF会尝试隐式转换，失败则返回NULL；建议先用STR_TO_DATE显式转，避免歧义 - MySQL 5.6+ 对非法日期（如
'2024-02-30'）默认转为'0000-00-00'，而TIMESTAMPDIFF遇到该值会返回NULL，需检查数据质量
替代方案：用DATEDIFF + TIME_TO_SEC处理跨天场景
如果只需要“总秒数”，且已知时间跨度不超过一天，可以用 TIME_TO_SEC(TIMEDIFF(end_time, start_time))。但它不处理跨天——比如从昨天 23:59:59 到今天 00:00:01，TIMEDIFF 返回负值或溢出，结果不可靠。真正需要跨天秒数时，TIMESTAMPDIFF(SECOND, ...) 是唯一安全选择。
-
TIMEDIFF返回的是TIME类型，最大支持838:59:59，超限就截断，不适合长时间跨度 -
DATEDIFF只算天数，精度不够；组合TIME_TO_SEC无法还原完整秒差 - 没有比
TIMESTAMPDIFF(SECOND, a, b)更简洁可靠的跨天秒数计算方式了
真正容易被忽略的是单位参数大小写敏感性：MySQL 文档写明单位关键字不区分大小写，但某些旧版本驱动或中间件（如某些 JDBC 封装）可能强制大写；保险起见，统一用全大写 SECOND。
