应使用 TIMESTAMPDIFF 而非 DATEDIFF 以保留秒级精度，因 DATEDIFF 仅返回整数天数且忽略时分秒；TIMESTAMPDIFF 支持 SECOND/MINUTE/HOUR 等单位，按实际日历差计算，需注意参数顺序、时间格式、NULL 校验及时区一致性。
用 TIMESTAMPDIFF 而不是 DATEDIFF，否则秒级精度直接丢光
在 MySQL 存储过程中，DATEDIFF 只返回整数天数，连小时都砍掉——它压根不看时分秒。如果你要算“从用户提交到审核通过耗时多少秒”，用 DATEDIFF 得到的永远是 0（同一天）或 1（隔天），毫无业务意义。
TIMESTAMPDIFF 才是正解，它支持 SECOND、MINUTE、HOUR 等单位，且严格按实际时间差计算：
SET @diff_sec = TIMESTAMPDIFF(SECOND, '2026-10-14 09:23:15', '2026-10-14 11:47:32');
注意三点：
-
TIMESTAMPDIFF参数顺序是TIMESTAMPDIFF(unit, start_time, end_time)，start 在前、end 在后，反了会得负数 - 两个时间参数必须能被 MySQL 自动识别为 datetime 或 timestamp；传字符串时建议用标准格式
'YYYY-MM-DD HH:MM:SS'，避免隐式转换失败 - 如果变量是
DATETIME类型，直接传变量名即可，不用额外转格式
存储过程里别硬写字符串时间，用变量 + NOW() 或 CURRENT_TIMESTAMP 动态取值
硬编码时间字符串只适合测试，真实存储过程里时间点基本来自输入参数或当前系统时间。比如记录操作耗时，你通常需要：
- 入口处用
SET start_time = NOW();捕获开始时刻 - 关键逻辑执行完，再用
SET end_time = NOW(); - 最后
SET duration_sec = TIMESTAMPDIFF(SECOND, start_time, end_time);
不要用 CURDATE() + CURTIME() 拼接——它可能在毫秒级边界产生错位（比如 CURDATE() 返回 2026-10-14，CURTIME() 返回 12:53:29.999，但两次调用之间其实已跨毫秒）。NOW() 或 CURRENT_TIMESTAMP 是原子操作，一次取全。
小心 TIMESTAMPDIFF 对 NULL 和非法时间的静默失败
如果任一参数是 NULL，TIMESTAMPDIFF 直接返回 NULL，不会报错，后续计算可能意外中断或插入空值。常见翻车场景：
- 输入参数未设默认值，调用时漏传，
start_time为NULL - 字段本身允许 NULL，查询结果带入计算时没做判断
- 时间字符串格式错误（如
'2026-13-01'），MySQL 会转成'0000-00-00 00:00:00'，导致差值巨大且难以排查
稳妥做法是在计算前加校验：
IF start_time IS NULL OR end_time IS NULL OR start_time = '0000-00-00 00:00:00' OR end_time = '0000-00-00 00:00:00' THEN SET duration_sec = 0; ELSE SET duration_sec = TIMESTAMPDIFF(SECOND, start_time, end_time); END IF;
跨天/跨月计算时，TIMESTAMPDIFF 的单位选择直接影响语义
TIMESTAMPDIFF 不是简单除法，它按日历单位向下取整。例如：
-
TIMESTAMPDIFF(HOUR, '2026-10-14 23:59:00', '2026-10-15 00:01:00')返回0（不足 1 小时） -
TIMESTAMPDIFF(MINUTE, ...)同样返回2，不是62
这意味着：选什么单位，就决定了你“怎么定义耗时”。业务要求“满一小时计 1 小时”，就用 HOUR；要求“精确到秒”，必须用 SECOND 并自行处理四舍五入或向上取整（比如用 CEIL(duration_sec / 3600.0)）。
最容易被忽略的是：这个函数不处理时区。如果存储过程运行在 SYSTEM 时区，而输入时间是 UTC 字符串，差值会偏移 8 小时（以东八区为例）。上线前务必确认所有时间值是否在同一时区上下文里。
