FROM_UNIXTIME将时间戳转为DATETIME，按会话时区解释；UNIX_TIMESTAMP将日期转为时间戳，也依赖会话时区。二者均受时区影响，需显式设time_zone或用时区参数避免偏差。
FROM_UNIXTIME 把时间戳转成可读日期，但默认用系统时区
MySQL 的 FROM_UNIXTIME 接收一个整数时间戳（秒级），返回 DATETIME 类型值。它不直接存时区信息，而是按当前会话时区解释——比如你服务器在 UTC+8，传入 1717027200（对应 2024-05-30 00:00:00 UTC），FROM_UNIXTIME(1717027200) 会显示为 2024-05-30 08:00:00。
常见错误现象：
— 查询结果日期比预期早/晚 8 小时
— 同一时间戳在不同服务器上显示不同日期
- 显式指定时区：用
FROM_UNIXTIME(1717027200, '+00:00')强制按 UTC 解析 - 改会话时区更稳妥：执行
SET time_zone = '+00:00'后再调用FROM_UNIXTIME - 注意：如果字段本身是
TIMESTAMP类型，MySQL 自动做时区转换；DATETIME不转，所以别混用
UNIX_TIMESTAMP 转日期回时间戳，参数类型决定行为
UNIX_TIMESTAMP 是个重载函数：不带参返回当前时间戳；传字符串会尝试解析；传 DATETIME 或 DATE 值则转为对应秒数。关键在于它**始终按会话时区理解输入值**。
使用场景：
— 日志表里存的是 '2024-05-30' 字符串，想算距今几天
— 需要按天聚合，把 DATETIME 截断到 00:00 再转时间戳
- 传字符串时必须符合 MySQL 默认格式（如
'2024-05-30 14:30:00'），否则返回0或NULL - 传
DATE值（如CURDATE()）会被当成当天 00:00:00 处理，时区影响依然存在 - 性能提示：在 WHERE 中对列用
UNIX_TIMESTAMP(col)会导致索引失效，应改写为范围查询（如col >= '2024-05-30' AND col ）
跨时区存储建议：统一用 UTC 时间戳 + 显式转换
如果业务涉及多地区用户，别依赖 FROM_UNIXTIME 默认行为。时间戳本质是 UTC 秒数，最稳的方式是：入库全用 UTC 时间戳（或 TIMESTAMP 类型），查的时候按需转本地时间。
- 写入前用
UNIX_TIMESTAMP(CONVERT_TZ(NOW(), @@session.time_zone, '+00:00'))确保存的是 UTC 秒数 - 查询时用
FROM_UNIXTIME(ts, '+08:00')指定目标时区，而不是靠会话变量 - 避免用
UNIX_TIMESTAMP('2024-05-30')这种写法——字符串没带时区，MySQL 按 session 解析，不可控 -
TIMESTAMP列自动转时区，但最大只支持到 2038 年；INT存时间戳更灵活，只是得自己转
常见报错和边界情况
这两个函数看着简单，但几个边界值容易出问题：
-
FROM_UNIXTIME(0)返回'1970-01-01 08:00:00'（UTC+8 下），不是'1970-01-01 00:00:00' - 传入负数时间戳（如
-3600）能正常工作，但部分旧版 MySQL 或客户端可能显示异常 -
UNIX_TIMESTAMP('0000-00-00')返回0，但FROM_UNIXTIME(0)不一定还原成这个零日期（取决于 SQL mode） - 毫秒级时间戳不能直接用：MySQL 原生只认秒级，得先除以 1000 并转整型，比如
FROM_UNIXTIME(FLOOR(1717027200123 / 1000))
时区和精度是连着的，漏掉任何一个，时间就容易差几小时甚至一整天。
