SEC_TO_TIME对负数返回NULL而非负时间；因其设计仅支持非负秒数，需用IF判断符号、取绝对值后拼接'-'前缀实现负时间字符串。
SEC_TO_TIME 会把负数变成 NULL，不是你想要的“负时间”
MySQL 的 SEC_TO_TIME 函数对负秒数不友好：传入 -3661，它不会返回 -01:01:01，而是直接返回 NULL。这是很多做工时统计、超时预警的人踩的第一个坑。
原因在于 MySQL 官方定义中，SEC_TO_TIME 设计用于转换“自午夜起经过的秒数”，隐含非负前提。真要处理负值，得自己兜底：
- 先用
IF或CASE判断符号，拆出绝对值 - 对绝对值调用
SEC_TO_TIME - 再拼上前缀
'-'（注意：结果是字符串，不再是 TIME 类型）
示例：SELECT CONCAT(IF(-3661 → <code>'-01:01:01'
SEC_TO_TIME 返回的是 TIME 类型，但精度只到秒
SEC_TO_TIME 输出是 TIME 类型，不是字符串，也不是带毫秒的 TIME(3)。哪怕你传入 3661.123，它也会自动截断小数部分，等价于 SEC_TO_TIME(3661)，结果恒为 '01:01:01'。
如果你需要毫秒级时间表示（比如日志分析），别指望它：
- 不能直接保留小数 ——
SEC_TO_TIME参数被强制转为整数 - 想显示毫秒？得自己用
FLOOR()和MOD()分离整秒和毫秒，再拼接字符串 - 注意：拼出来的结果是
VARCHAR，无法参与原生 TIME 运算
和 TIMESTAMPDIFF 配合算两个时间点的时分，别直接减
常见需求：算 start_time 到 end_time 之间几小时几分？很多人写 end_time - start_time，结果得到一串数字（如 10234），误以为是秒——其实那是 MySQL 的“时间相减伪格式”，不可靠。
正确链路是：
- 用
TIMESTAMPDIFF(SECOND, start_time, end_time)精确拿到秒数差（支持负值） - 再套一层
SEC_TO_TIME转成时分秒格式 - 但如果差值超过 838:59:59（
TIME上限），SEC_TO_TIME会截断为'838:59:59'，无声失败
超长间隔建议改用 CONCAT + FLOOR 手动算天/小时/分钟，避开 TIME 类型限制。
在 GROUP BY 或 ORDER BY 里用 SEC_TO_TIME 要小心隐式转换
把 SEC_TO_TIME(seconds_col) 放进 GROUP BY，看着是按“时分秒”分组，实际 MySQL 是按底层 TIME 值比较。而 TIME 类型在排序/分组时会归一化：比如 '00:00:00' 和 '24:00:00' 被视为相同值。
更隐蔽的问题是时区无关性：SEC_TO_TIME 不受 time_zone 设置影响，永远按本地时钟零点算。如果你的数据本身带时区偏移（比如存的是 UTC 时间戳），先用 CONVERT_TZ 对齐，再算秒数，否则分组结果会错位。
简单说：它只认数字，不认上下文。用之前，先确认输入的秒数是不是你真正想表达的那个“时间跨度”。
