将13位毫秒时间戳转为标准日期需先除以1000转为秒级，再用FROM_unixTIME()函数转换；反向则用UNIX_timestamp()函数转为秒级时间戳后乘以1000，但会丢失毫秒精度。
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()
会尝试把这个巨大的数字当作秒数来转换，结果往往会得到一个遥远的未来日期，或者直接溢出报错，因为这个秒数已经超出了它能表示的范围。
所以，这不是
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里。数据库应该更专注于数据的存储和基本的查询。
