SEC_TO_TIME将整数秒转为HOUR:MINUTE:SECOND格式的TIME值，支持负数和超24小时显示，但超出-838:59:59~838:59:59范围时静默截断，且与TIME_TO_SEC配合存在小数秒精度丢失风险。
SEC_TO_TIME函数的基本用法和返回格式
SEC_TO_TIME 是 MySQL 提供的内置时间转换函数，直接把一个整数秒数转成 HOUR:MINUTE:SECOND 格式的 TIME 值。它不处理时区，也不做日期部分计算，只专注“纯秒数→时分秒”这一件事。
注意：返回值类型是 TIME，不是字符串；如果想拼接到其他文本里，得显式用 CAST 或 CONVERT 转成 VARCHAR。
-
SEC_TO_TIME(3661)返回'01:01:01'（1小时1分1秒） -
SEC_TO_TIME(-3661)返回'-01:01:01'（支持负数） -
SEC_TO_TIME(86400)返回'24:00:00'（超过24小时会照常显示，不会进位成 1 天）
秒数超限时的隐式截断行为
MySQL 的 TIME 类型有范围限制：-838:59:59 到 +838:59:59。一旦输入秒数超出对应范围（即 ABS(seconds) > 3020399），SEC_TO_TIME 不报错，而是静默截断到边界值。
-
SEC_TO_TIME(3020400)→'838:59:59'（不是你预期的'839:00:00'） -
SEC_TO_TIME(-3020400)→'-838:59:59' - 这种截断不可逆，且无警告——如果你在统计任务耗时或视频时长，必须提前校验输入值
与TIME_TO_SEC配合做双向转换时的精度陷阱
TIME_TO_SEC 把 TIME 值转回秒数，看起来是 SEC_TO_TIME 的逆操作，但要注意小数秒支持问题：
-
SEC_TO_TIME(3661.5)返回'01:01:01.500000'（支持微秒，取决于 MySQL 版本和列定义） - 但如果原
TIME列定义为TIME（无精度），存储时会丢弃小数部分 -
TIME_TO_SEC(SEC_TO_TIME(3661.5))在多数场景下返回3661，不是3661.5 - 若需保留小数秒，请确保字段定义为
TIME(6)并确认客户端/驱动支持
在聚合查询中使用SEC_TO_TIME的常见错误
很多人想对“总秒数”求和后统一转成时分秒，比如统计用户每日在线时长：
SELECT SEC_TO_TIME(SUM(duration_sec)) FROM user_log WHERE date = '2024-06-01';
这本身没问题，但容易踩两个坑：
- 如果
SUM结果为NULL（比如没数据），SEC_TO_TIME(NULL)返回NULL，不是'00:00:00'；需要加COALESCE(SUM(...), 0) - 若
duration_sec是浮点类型（如DOUBLE），求和可能引入浮点误差，导致SEC_TO_TIME输出意外的小数秒；建议用ROUND(SUM(...))强制取整 - 别在
WHERE或JOIN条件里用SEC_TO_TIME做比较——它无法走索引，应把逻辑移到秒数层面
真正难处理的是跨天累计、带毫秒精度的业务场景，这时候光靠 SEC_TO_TIME 不够，得结合 TIME 运算或应用层解析。
