sec_to_time将整数秒转为time类型'hh:mm:ss'，超3020399秒返回null；不支持索引，应转为秒数过滤排序；与time_to_sec配合实现耗时聚合，展示时建议用time_format控制格式。
SEC_TO_TIME函数的基本用法和返回值类型
SEC_TO_TIME 是 MySQL 中将整数秒数转换为 TIMESTAMP 风格的 TIME 值（格式为 'HH:MM:SS'）的内置函数。它不接受字符串或浮点数，只处理整数秒数；传入小数会自动截断（不是四舍五入），比如 SEC_TO_TIME(3661.9) 等价于 SEC_TO_TIME(3661)，结果是 '01:01:01'。
注意：返回的是 TIME 类型，不是字符串——这意味着它可参与时间运算（如加减 INTERVAL），但直接用于拼接或导出时可能被隐式转成字符串，此时格式固定为 HH:MM:SS（不足两位不补零，例如 SEC_TO_TIME(5) 返回 '00:00:05'，不是 '5'）。
处理超过24小时的秒数时要注意什么
MySQL 的 TIME 类型支持范围是 '-838:59:59' 到 '838:59:59'，所以 SEC_TO_TIME 能安全处理的最大秒数是 838 * 3600 + 59 * 60 + 59 = 3020399 秒（约 35 天）。超出这个值会返回 NULL，且无警告。
- 若需显示 >24 小时的持续时间（如视频时长、任务耗时），不要依赖
SEC_TO_TIME直接展示，而应自行计算：SELECT CONCAT(FLOOR(total_seconds / 3600), ':', LPAD(FLOOR((total_seconds % 3600) / 60), 2, '0'), ':', LPAD(total_seconds % 60, 2, '0')) AS duration FROM (SELECT 9075 AS total_seconds) t;（结果：'02:31:15'） -
SEC_TO_TIME对超限值静默返回NULL，建议加IFNULL或前置校验：IF(total_seconds > 3020399, 'OVERFLOW', SEC_TO_TIME(total_seconds))
在 ORDER BY 或 WHERE 中使用 SEC_TO_TIME 的性能影响
SEC_TO_TIME 是标量函数，无法利用索引。如果字段是存储秒数的整型（如 duration_sec INT），直接在 WHERE 中写 SEC_TO_TIME(duration_sec) > '01:00:00' 会导致全表扫描。
- 正确做法是把条件转回秒数：
WHERE duration_sec > 3600 - 排序同理：用
ORDER BY duration_sec，而不是ORDER BY SEC_TO_TIME(duration_sec) - 如果高频需要按格式化后的时间排序/过滤，考虑增加生成列并建索引：
ALTER TABLE tasks ADD COLUMN duration_time TIME AS (SEC_TO_TIME(duration_sec)) STORED, ADD INDEX idx_duration_time (duration_time);
与 TIME_TO_SEC 配合使用的典型场景
这两个函数互为逆操作，常见于「统计某段时间内累计秒数」类需求，比如日志表中记录每条操作的耗时（单位：秒），再按小时聚合。
- 错误示例（试图对
TIME字段直接求和）：SUM(exec_time)—— MySQL 会把TIME当作“时间点”相加，结果不可控 - 正确链路：
TIME_TO_SEC(exec_time)→ 聚合 →SEC_TO_TIME(SUM(...))SELECT HOUR(created_at) AS hour, SEC_TO_TIME(SUM(TIME_TO_SEC(exec_time))) AS total_duration FROM logs GROUP BY HOUR(created_at);
- 注意：
TIME_TO_SEC对NULL返回NULL，聚合前建议用COALESCE(TIME_TO_SEC(exec_time), 0)避免整组被忽略
真正容易被忽略的是：SEC_TO_TIME 的输出是 TIME 类型，它在某些客户端（如旧版 MySQL Workbench 或某些 ORM）里可能被自动转成日期时间格式，或者因时区设置出现偏移；如果只是做展示，显式转成字符串更可控：TIME_FORMAT(SEC_TO_TIME(seconds), '%H:%i:%s')。
