如何使用MySQL FROM_UNIXTIME函数将Unix时间戳转换成日期格式？
- 内容介绍
- 文章标签
- 相关推荐
本文共计907个文字，预计阅读时间需要4分钟。
FROM_UNIXTIME 是 MySQL 中将 Unix 时间戳（即从 1970-01-01 00:00:00 UTC 开始的秒数）转换为日期时间字符串的函数。默认返回的格式为 DATETIME 类型，格式为 'YYYY-MM-DD HH:MM:SS'。
常见误用是把毫秒级时间戳直接传进去——FROM_UNIXTIME 只接受**秒级整数**，传入 1717023600000 这样的毫秒值会得到错误结果（比如公元 56379 年）。
- 正确：
FROM_UNIXTIME(1717023600)→'2024-05-30 15:00:00' - 错误：
FROM_UNIXTIME(1717023600000)→ 解析成远超预期的年份 - 若只有毫秒值，先除以 1000 并用
FLOOR或CAST(... AS UNSIGNED)截断小数：FROM_UNIXTIME(FLOOR(1717023600000 / 1000))
指定输出格式：第二个参数 format 的作用
FROM_UNIXTIME 支持可选的第二个参数 format，用类似 DATE_FORMAT 的格式符自定义输出字符串。这个参数不改变返回类型——即使你写成 '%Y年%m月%d日'，结果仍是 VARCHAR，不是 DATE。
注意：格式符中不能包含时区偏移（如 %f 微秒、%V 周号等）以外的非标准字符；MySQL 不支持 %z 或 %Z 输出时区缩写。
- 只取日期：
FROM_UNIXTIME(1717023600, '%Y-%m-%d')→'2024-05-30' - 中文格式：
FROM_UNIXTIME(1717023600, '%Y年%m月%d日 %H时%i分%s秒') - 想转成
DATE类型？需额外包裹DATE()：DATE(FROM_UNIXTIME(1717023600))
时区问题：FROM_UNIXTIME 默认使用系统时区
FROM_UNIXTIME 的结果受 MySQL 服务端时区影响，不是简单“加8小时”。例如服务器时区设为 '+00:00'，而你传入的是东八区本地生成的时间戳（如 PHP time()），结果会比预期晚 8 小时。
验证当前会话时区：SELECT @@session.time_zone;。安全做法是在转换前显式设置时区，或统一在应用层处理时区转换。
- 临时切换会话时区：
SET time_zone = '+08:00';，再执行FROM_UNIXTIME - 跨时区存储建议：时间戳字段用
INT存秒值，查询时用CONVERT_TZ配合FROM_UNIXTIME：CONVERT_TZ(FROM_UNIXTIME(ts), '+00:00', '+08:00') - 避免依赖全局
default-time-zone配置，因为不同环境可能不一致
性能与索引：不要在 WHERE 条件里对列用 FROM_UNIXTIME
如果表里有个 created_at_ts 字段存的是 Unix 时间戳（INT），想查某天的数据，别写 WHERE DATE(FROM_UNIXTIME(created_at_ts)) = '2024-05-30'——这会让 MySQL 无法使用该字段上的索引，全表扫描不可避免。
正确做法是把条件反向推算回时间戳范围：
- 查 2024-05-30 当天：
WHERE created_at_ts BETWEEN UNIX_TIMESTAMP('2024-05-30') AND UNIX_TIMESTAMP('2024-05-30 23:59:59') - 或者更简洁：
WHERE created_at_ts >= UNIX_TIMESTAMP('2024-05-30') AND created_at_ts - 确保
created_at_ts字段有索引，且类型是INT或BIGINT（够存到 2106 年）
真正容易被忽略的点是：时间戳字段本身是否带索引、有没有被隐式类型转换（比如跟字符串比较）、以及 UNIX_TIMESTAMP 的调用开销虽小，但在大结果集上仍建议预计算。
本文共计907个文字，预计阅读时间需要4分钟。
FROM_UNIXTIME 是 MySQL 中将 Unix 时间戳（即从 1970-01-01 00:00:00 UTC 开始的秒数）转换为日期时间字符串的函数。默认返回的格式为 DATETIME 类型，格式为 'YYYY-MM-DD HH:MM:SS'。
常见误用是把毫秒级时间戳直接传进去——FROM_UNIXTIME 只接受**秒级整数**，传入 1717023600000 这样的毫秒值会得到错误结果（比如公元 56379 年）。
- 正确：
FROM_UNIXTIME(1717023600)→'2024-05-30 15:00:00' - 错误：
FROM_UNIXTIME(1717023600000)→ 解析成远超预期的年份 - 若只有毫秒值，先除以 1000 并用
FLOOR或CAST(... AS UNSIGNED)截断小数：FROM_UNIXTIME(FLOOR(1717023600000 / 1000))
指定输出格式：第二个参数 format 的作用
FROM_UNIXTIME 支持可选的第二个参数 format，用类似 DATE_FORMAT 的格式符自定义输出字符串。这个参数不改变返回类型——即使你写成 '%Y年%m月%d日'，结果仍是 VARCHAR，不是 DATE。
注意：格式符中不能包含时区偏移（如 %f 微秒、%V 周号等）以外的非标准字符；MySQL 不支持 %z 或 %Z 输出时区缩写。
- 只取日期：
FROM_UNIXTIME(1717023600, '%Y-%m-%d')→'2024-05-30' - 中文格式：
FROM_UNIXTIME(1717023600, '%Y年%m月%d日 %H时%i分%s秒') - 想转成
DATE类型？需额外包裹DATE()：DATE(FROM_UNIXTIME(1717023600))
时区问题：FROM_UNIXTIME 默认使用系统时区
FROM_UNIXTIME 的结果受 MySQL 服务端时区影响，不是简单“加8小时”。例如服务器时区设为 '+00:00'，而你传入的是东八区本地生成的时间戳（如 PHP time()），结果会比预期晚 8 小时。
验证当前会话时区：SELECT @@session.time_zone;。安全做法是在转换前显式设置时区，或统一在应用层处理时区转换。
- 临时切换会话时区：
SET time_zone = '+08:00';，再执行FROM_UNIXTIME - 跨时区存储建议：时间戳字段用
INT存秒值，查询时用CONVERT_TZ配合FROM_UNIXTIME：CONVERT_TZ(FROM_UNIXTIME(ts), '+00:00', '+08:00') - 避免依赖全局
default-time-zone配置，因为不同环境可能不一致
性能与索引：不要在 WHERE 条件里对列用 FROM_UNIXTIME
如果表里有个 created_at_ts 字段存的是 Unix 时间戳（INT），想查某天的数据，别写 WHERE DATE(FROM_UNIXTIME(created_at_ts)) = '2024-05-30'——这会让 MySQL 无法使用该字段上的索引，全表扫描不可避免。
正确做法是把条件反向推算回时间戳范围：
- 查 2024-05-30 当天：
WHERE created_at_ts BETWEEN UNIX_TIMESTAMP('2024-05-30') AND UNIX_TIMESTAMP('2024-05-30 23:59:59') - 或者更简洁：
WHERE created_at_ts >= UNIX_TIMESTAMP('2024-05-30') AND created_at_ts - 确保
created_at_ts字段有索引，且类型是INT或BIGINT（够存到 2106 年）
真正容易被忽略的点是：时间戳字段本身是否带索引、有没有被隐式类型转换（比如跟字符串比较）、以及 UNIX_TIMESTAMP 的调用开销虽小，但在大结果集上仍建议预计算。