FROM_UNIXTIME将秒级时间戳转为DATETIME类型，默认按服务器时区解析；带格式参数时返回字符串且不可参与日期运算；WHERE中误用会导致索引失效，应改用UNIX_TIMESTAMP转换条件；跨时区需显式指定时区避免歧义。
FROM_UNIXTIME 函数的基本用法和返回类型
FROM_UNIXTIME 把 Unix 时间戳（秒级整数）转成 MySQL 默认格式的日期时间字符串，比如 '2024-05-22 14:30:45'。它默认返回 DATETIME 类型，不是字符串——这点容易被忽略，尤其在做类型比较或插入时出错。
最简调用就是 FROM_UNIXTIME(1716388245)，结果是 '2024-05-22 14:30:45'。注意：输入必须是整数（秒），不能是毫秒；若传入毫秒值（如 JavaScript 的 Date.now()），得先除以 1000 并用 FLOOR 或 CAST 转整型，否则会截断或报错。
带格式化参数的 FROM_UNIXTIME 使用场景
第二个参数支持 STRFTIME 风格的格式符，例如 FROM_UNIXTIME(1716388245, '%Y年%m月%d日 %H:%i') 返回 '2024年05月22日 14:30'。这个参数是可选的，但一旦使用，返回值就变成 STRING，不再具备日期计算能力。
- 常用格式符：
%Y（4位年）、%m（补零月）、%d（补零日）、%H（24小时制）、%i（分钟）、%s（秒） - 避免用
%y（2位年）或%c（无补零月），易引发排序或分组异常 - 格式化后的结果无法直接参与
DATE_ADD、BETWEEN等日期运算，需先转回DATETIME
在 WHERE 子句中误用 FROM_UNIXTIME 导致性能问题
常见错误是写成 WHERE FROM_UNIXTIME(created_at) > '2024-01-01'。这会让 MySQL 对每行都执行函数计算，无法使用 created_at 字段上的索引，全表扫描不可避免。
正确做法是把条件转为时间戳比较：WHERE created_at > UNIX_TIMESTAMP('2024-01-01')。这样索引能生效，且语义更清晰——原始字段是时间戳，就该用时间戳逻辑去查。
如果字段本身是 DATETIME 类型，又想按时间戳过滤，才用 UNIX_TIMESTAMP(col) 做转换；反过来，别在 WHERE 里对索引列套 FROM_UNIXTIME。
时区影响和跨时区查询的坑
FROM_UNIXTIME 默认按 MySQL 服务端时区解释时间戳。比如时间戳 1716388245 在 UTC 是 '2024-05-22 06:30:45'，但在 SYSTEM 时区（如东八区）就显示为 '2024-05-22 14:30:45'。如果应用部署在多个时区，或数据来自不同时区的客户端，这个差异会导致查询结果不一致。
安全做法是显式指定时区：
-
FROM_UNIXTIME(1716388245, '+00:00')强制按 UTC 解释 - 或先设会话时区：
SET time_zone = '+00:00';再执行查询 - 注意：
CONVERT_TZ(FROM_UNIXTIME(ts), '+00:00', '+08:00')是冗余操作，不如直接用FROM_UNIXTIME(ts + 28800)（+8 小时秒数）
真正麻烦的是历史数据混有时区来源，而时间戳没带时区元信息——这种情况下，FROM_UNIXTIME 只能按当前配置“猜”，没有银弹。
