from_unixtime默认返回mysql服务器当前时区的本地时间；其结果取决于time_zone系统变量，而非utc或客户端时区，且自5.7.30起支持第二个参数指定目标时区以实现utc时间戳到本地时间的正确转换。
FROM_UNIXTIME 默认返回的是什么时区时间？
FROM_UNIXTIME 函数本身不处理时区转换，它直接把 Unix 时间戳（秒数）解释为 **MySQL 服务器当前时区下的本地时间**。也就是说，结果取决于 time_zone 系统变量的值，不是 UTC，也不是你客户端所在时区，更不是“自动适配”。
常见错误现象：FROM_UNIXTIME(1717027200) 在北京服务器上返回 2024-05-31 08:00:00，但在美国西海岸服务器上可能返回 2024-05-30 16:00:00 —— 同一个时间戳，结果不同。
- 查当前会话时区：
SELECT @@session.time_zone; - 临时设为东八区（+08:00）：
SET time_zone = '+08:00'; - 设为系统默认时区：
SET time_zone = 'SYSTEM'; - 生产环境建议在连接初始化 SQL 中统一设置，而不是依赖服务器默认值
如何把 Unix 时间戳转成指定时区的本地时间？
MySQL 5.7.30+ 支持在 FROM_UNIXTIME 第二个参数传入时区偏移或命名时区，例如：FROM_UNIXTIME(1717027200, '+08:00') 或 FROM_UNIXTIME(1717027200, 'Asia/Shanghai')。
但注意：FROM_UNIXTIME(ts, 'Asia/Shanghai') 的行为是「把 ts 当作 UTC 时间，再转成上海本地时间」—— 这才是多数人想要的「Unix 时间戳（本质是 UTC 秒数）→ 某地本地时间」逻辑。
- Unix 时间戳定义就是「自 1970-01-01 00:00:00 UTC 起经过的秒数」，所以它天然对应 UTC
- 因此正确用法是：
FROM_UNIXTIME(ts, 'Asia/Shanghai')，不是FROM_UNIXTIME(ts)加 SET time_zone - 使用命名时区前需确认 MySQL 已加载时区表（运行
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql） - 若无法加载命名时区，用
'+08:00'更稳妥，但注意夏令时不会自动调整
FROM_UNIXTIME 返回的时间精度和格式能控制吗？
FROM_UNIXTIME 默认返回 DATETIME 类型，格式固定为 YYYY-MM-DD HH:MM:SS。如果只需要日期部分、或想转成字符串自定义格式，得配合 DATE() 或 DATE_FORMAT()。
- 只取日期：
DATE(FROM_UNIXTIME(1717027200, '+08:00'))→2024-05-31 - 自定义格式（如年月日中文）：
DATE_FORMAT(FROM_UNIXTIME(1717027200, '+08:00'), '%Y年%m月%d日') - 注意：
DATE_FORMAT输入必须是日期/时间类型，不能直接对时间戳用，否则结果不可靠 - 性能提示：在 WHERE 条件里对字段用
FROM_UNIXTIME(col)会导致索引失效，应考虑存储为 DATETIME 并建索引，或用时间戳范围查询
为什么 FROM_UNIXTIME 结果和 Python/JS 显示不一致？
根本原因往往是时区理解错位：Python 的 datetime.fromtimestamp(1717027200) 默认用本地系统时区，JS 的 new Date(1717027200 * 1000) 默认用浏览器时区，而 MySQL 的 FROM_UNIXTIME 默认用服务器时区 —— 三者没对齐。
- 验证方法：统一换算成 UTC 时间对比，例如都用
datetime.utcfromtimestamp(1717027200)（Python）、new Date(1717027200 * 1000).toUTCString()（JS）、FROM_UNIXTIME(1717027200, '+00:00')（MySQL） - 跨系统联调时，建议所有环节显式声明时区，避免依赖隐式默认
- 特别注意：MySQL 8.0.19+ 对
FROM_UNIXTIME的时区参数校验更严格，传错时区名会报错ER_UNKNOWN_TIME_ZONE，不是静默失败
时区不是可选配置，是计算逻辑的一部分；FROM_UNIXTIME 的第二个参数不是锦上添花，而是明确语义的必要手段。
