MySQL日期转换函数 13位时间戳转标准日期的代码示例-mysql教程-PHP中文网

MySQL日期转换函数 13位时间戳转标准日期的代码示例

看不見的法師

发布： 2025-08-23 12:12:02

原创

326人浏览过

将13位毫秒时间戳转为标准日期需先除以1000转为秒级，再用FROM_UNIXTIME()函数转换；反向则用UNIX_TIMESTAMP()函数转为秒级时间戳后乘以1000，但会丢失毫秒精度。

mysql日期转换函数 13位时间戳转标准日期的代码示例

MySQL中，要把一个13位的Unix时间戳（通常是毫秒级）转换成标准日期格式，最直接的方法是先将其除以1000，变成10位的秒级时间戳，再利用

FROM_UNIXTIME()

登录后复制

函数进行转换。这其实是个挺常见的需求，毕竟很多前端或者其他系统默认给的都是毫秒级时间戳。

解决方案

处理13位时间戳到标准日期，核心思路就是降维打击——把毫秒变成秒。MySQL的

FROM_UNIXTIME()

登录后复制

函数是为10位秒级时间戳设计的，所以我们只需要一个简单的除法操作。

假设你有一个名为

timestamp_ms

登录后复制

的列，里面存的是13位的毫秒时间戳：

SELECT
    FROM_UNIXTIME(timestamp_ms / 1000) AS standard_datetime,
    FROM_UNIXTIME(timestamp_ms / 1000, '%Y-%m-%d %H:%i:%s') AS formatted_datetime
FROM
    your_table;

登录后复制

这里，

FROM_UNIXTIME(timestamp_ms / 1000)

登录后复制

会直接返回一个

DATETIME

登录后复制

类型的值，格式通常是

YYYY-MM-DD HH:MM:SS

登录后复制

。如果你需要更具体的格式，比如只显示日期或者只显示到分钟，可以加上第二个参数，像

'%Y-%m-%d %H:%i:%s'

登录后复制

那样。那个格式字符串的用法，和

DATE_FORMAT()

登录后复制

函数是完全一致的，非常灵活。

如果你的时间戳是字符串类型，记得先转换成数字，例如：

CAST(timestamp_ms AS DECIMAL(16, 3)) / 1000

登录后复制

，或者如果确保是纯数字字符串，MySQL通常能自动进行隐式转换，但显式转换总归更稳妥些。

为什么MySQL的FROM_UNIXTIME函数无法直接处理13位时间戳？

这个问题其实挺有意思的，也反映了Unix时间戳的历史和标准。我们通常说的Unix时间戳，它在设计之初就是以秒为单位的，表示从1970年1月1日00:00:00 UTC到现在的秒数。这是因为在那个年代，计算机的存储和处理能力都相对有限，精确到秒已经足够满足大部分需求了。所以，像

FROM_UNIXTIME()

登录后复制

这样的函数，它的内部实现逻辑就是基于这个“秒”的单位来解析的。

当你给它一个13位的数字时，它会把它当作一个非常大的秒数来处理，而不是毫秒。举个例子，如果你的13位时间戳是

1678886400000

登录后复制

（代表2023年3月15日），

FROM_UNIXTIME()

登录后复制

会尝试把这个巨大的数字当作秒数来转换，结果往往会得到一个遥远的未来日期，或者直接溢出报错，因为这个秒数已经超出了它能表示的范围。

快转字幕

新一代 AI 字幕工作站，为创作者提供字幕制作、学习资源、会议记录、字幕制作等场景，一键为您的视频生成精准的字幕。

357

查看详情

所以，这不是

FROM_UNIXTIME()

登录后复制

“不行”，而是它遵循的是一个更早、更普遍的“秒级时间戳”标准。我们现在之所以会遇到13位时间戳，更多是现代系统为了更高的精度（毫秒甚至微秒）而引入的扩展，尤其是在Web开发和分布式系统中，毫秒级精度变得越来越重要。因此，在不同标准之间转换时，就需要我们手动做一下单位换算。

如何将标准日期转换回13位时间戳？

既然能把13位时间戳转成日期，反过来操作自然也是可以的。如果你想把一个MySQL中的

DATETIME

登录后复制

或

TIMESTAMP

登录后复制

类型的值，转换回13位的毫秒级Unix时间戳，你需要用到

UNIX_TIMESTAMP()

登录后复制

函数，然后再乘以1000。

UNIX_TIMESTAMP()

登录后复制

函数的作用是把一个日期时间值转换成10位的秒级Unix时间戳。

SELECT
    UNIX_TIMESTAMP(NOW()) * 1000 AS current_timestamp_ms,
    UNIX_TIMESTAMP('2023-03-15 10:30:00') * 1000 AS specific_timestamp_ms,
    UNIX_TIMESTAMP(your_datetime_column) * 1000 AS column_timestamp_ms
FROM
    your_table;

登录后复制

这里需要注意一个细节：

UNIX_TIMESTAMP()

登录后复制

返回的是一个整数，它丢失了毫秒信息。也就是说，如果你把一个带毫秒的日期字符串（比如

'2023-03-15 10:30:00.123'

登录后复制

）传给

UNIX_TIMESTAMP()

登录后复制

，它只会取到秒的部分。所以，如果你最初的13位时间戳就是毫秒级的，并且转换成日期后再转回去，那么这期间的毫秒精度是会丢失的。除非你的日期列本身就存储了毫秒（比如使用

DATETIME(3)

登录后复制

或

TIMESTAMP(3)

登录后复制

），并且在转换时能捕获到这些毫秒信息。但通常情况下，

UNIX_TIMESTAMP()

登录后复制

是基于秒的，所以这种往返转换会损失毫秒精度，这在很多场景下需要特别注意。

在实际应用中，处理MySQL日期时间有哪些最佳实践？

在实际项目里，处理日期时间是个绕不开的话题，而且坑还不少。我个人觉得，有几个点是特别值得注意的：

统一存储标准： 无论是用
```
DATETIME
```
登录后复制
、
```
TIMESTAMP
```
登录后复制
还是
```
BIGINT
```
登录后复制
存时间戳，在一个项目里最好统一起来。我比较倾向于在数据库层面用
```
DATETIME
```
登录后复制
或
```
TIMESTAMP
```
登录后复制
来存日期时间，因为这样可读性好，而且MySQL本身有很多内置函数可以方便地操作。如果需要毫秒精度，那就用
```
DATETIME(3)
```
登录后复制
或
```
TIMESTAMP(3)
```
登录后复制
。如果非要存时间戳，那么建议存10位的秒级时间戳，或者直接存13位的毫秒级，但字段类型一定要是
```
BIGINT
```
登录后复制
，防止溢出。
时区管理： 这是个老大难问题。
```
TIMESTAMP
```
登录后复制
类型在存储时会自动转换为UTC，查询时再转回当前会话时区，这在处理跨时区应用时非常方便。而
```
DATETIME
```
登录后复制
则不会进行时区转换，存什么就是什么。所以，通常建议数据库存储UTC时间，在应用层或者查询时根据用户所在时区进行转换。这能避免很多因为时区不一致导致的数据混乱。
避免隐式转换： 尽量避免让MySQL去做隐式类型转换，比如把日期字符串直接和日期列比较。这不仅可能导致性能问题，还可能出现意想不到的错误。明确使用
```
STR_TO_DATE()
```
登录后复制
、
```
DATE_FORMAT()
```
登录后复制
、
```
UNIX_TIMESTAMP()
```
登录后复制
、
```
FROM_UNIXTIME()
```
登录后复制
等函数进行显式转换。
索引优化： 如果你的查询经常涉及到日期范围，确保日期时间列上有合适的索引。但要注意，在日期时间列上使用函数（比如
```
WHERE FROM_UNIXTIME(timestamp_ms / 1000) > '2023-01-01'
```
登录后复制
）可能会导致索引失效。这种情况下，最好把函数放到等号或比较符的另一边，或者在WHERE子句中将日期范围转换为时间戳范围进行比较。例如，将
```
'2023-01-01'
```
登录后复制
转换为对应的秒级时间戳，然后与
```
timestamp_ms / 1000
```
登录后复制
进行比较。
业务逻辑与数据库分离： 复杂的日期时间计算，比如跨年的周数计算、节假日判断等，更适合放在应用层处理，而不是全部塞进SQL里。数据库应该更专注于数据的存储和基本的查询。