SQL时间戳转可读日期：FROM_UNIXTIME函数用法

在日常开发中，时间戳与可读日期之间的转换是最常见的操作之一。MySQL 提供的 `FROM_UNIXTIME` 函数虽然简单，但坑点不少，尤其是时区、精度和跨数据库迁移时，稍不留神就会踩雷。下面把几个关键点掰开揉碎讲清楚，看完就能避开大部分坑。

FROM_UNIXTIME函数的基本用法和参数差异

`FROM_UNIXTIME` 的作用就是把秒级 Unix 时间戳转成可读的日期时间字符串，默认格式是 `'Y-m-d H:i:s'`。比如 `FROM_UNIXTIME(1717027200)` 返回 `'2024-05-30 00:00:00'`，理解起来很直观。 但有几个边界情况特别容易翻车： - **毫秒级时间戳**：如果从 Ja vaScript 前端传过来的时间戳是毫秒级的（比如 `Date.now()` 返回的值），直接丢进 `FROM_UNIXTIME` 会得到错误结果。必须先用 `FLOOR(ts / 1000)` 或者 `CAST(ts / 1000 AS UNSIGNED)` 转成秒级整数，再调用函数。 - **自定义格式**：第二个参数支持类似 `DATE_FORMAT` 的格式化语法。例如 `FROM_UNIXTIME(1717027200, '%Y年%m月%d日')` 会输出 `'2024年05月30日'`，适合直接做展示。 - **NULL 和非法值**：传入 `NULL` 或超出范围的数值（比如负数、非数字字符串），函数直接返回 `NULL`，不会报错。这就可能导致数据清洗时漏掉脏数据，需要特别留意。

常见错误：时区导致的日期偏移

时区问题是 `FROM_UNIXTIME` 最容易被忽视的坑。MySQL 默认使用当前会话的时区来解析时间戳，但它的实际逻辑是：**先把时间戳当作 UTC 时刻，再根据会话时区进行偏移显示**。 举个例子：假如服务器时区设置成 `+08:00`，那么 `FROM_UNIXTIME(0)` 并不会显示 `'1970-01-01 00:00:00'`，而是 `'1970-01-01 08:00:00'`。只要时区不一致，日期就会差几个小时。 解决方案有两个方向： - **统一会话时区**：执行 `SET time_zone = '+00:00';` 后再调用 `FROM_UNIXTIME`，所有输出都会变成 UTC 时间。 - **显式转换**：用 `CONVERT_TZ` 搭配时区字符串，避免依赖会话配置。比如 `CONVERT_TZ(FROM_UNIXTIME(ts), '+00:00', '+08:00')`，这样无论会话时区是什么，结果都是固定的目标时区。

替代方案：PostgreSQL 和 SQLite 怎么办

其他数据库没有 `FROM_UNIXTIME` 这个函数，但都有等效的实现方式： - **PostgreSQL**：使用 `TO_TIMESTAMP(ts)` 处理秒级时间戳，毫秒级就 `TO_TIMESTAMP(ts/1000.0)`，返回的是带时区的 `TIMESTAMP WITH TIME ZONE` 类型。 - **SQLite**：原生不支持时间戳函数，得靠 `datetime(ts, 'unixepoch')`。同样只接受秒级，毫秒级需要先除以 1000：`datetime(ts/1000, 'unixepoch')`。 - **边界行为差异**：对于 NULL 或溢出值（如超大时间戳），MySQL 返回 NULL，PostgreSQL 会直接报错，SQLite 则可能返回奇怪的字符串。跨数据库迁移时，这些差异需要单独处理。

性能与索引注意事项

`FROM_UNIXTIME` 是计算型函数，如果直接把它用在 WHERE 或 ORDER BY 中，会导致索引失效，引发全表扫描。这是一个常见的性能陷阱。 - **错误写法**：`WHERE FROM_UNIXTIME(created_ts) > '2024-01-01'`。这种写法无法利用 `created_ts` 字段上的索引，数据量大时性能会急剧下降。 - **正确写法**：`WHERE created_ts > UNIX_TIMESTAMP('2024-01-01')`。把日期字符串转回时间戳再比较，索引就能正常生效。 - **进一步优化**：如果经常需要按日期范围查询，可以考虑在 MySQL 5.7+ 中使用生成列。比如创建一个 `date_only DATE AS (DATE(FROM_UNIXTIME(created_ts))) STORED`，然后给这个生成列加索引，查询时直接 `WHERE date_only > '2024-01-01'`，既清晰又高效。 总结下来，`FROM_UNIXTIME` 本身不复杂，但时区、精度和索引方面的细节一旦漏掉，就可能造成数据偏差或性能瓶颈。尤其是在跨数据库迁移或前后端时间戳精度不一致的场景下，提前做好兼容处理能省去大量排查时间。