MySQL使用FROM_UNIXTIME转换时间戳timestamp无效问题原因

问题点在于timestamp的长度，检查下存储在数据库里的时间戳的数据格式及长度。

MySQL的FROM_UNIXTIME函数默认处理的是10位的时间戳，不是10位就会出现无效的情况，但是数据库并不会进行异常提示。

一般情况下，普遍遇到的是10位或者13位的时间戳，对于13位的时间戳，除以1000即可正常进行处理。示例代码如下：

SELECT FROM_UNIXTIME((submit_time/1000), '%Y-%m')
FROM tech_innovation.t_count_software_copyright;

下面稍微啰嗦两句为什么会出现这种情况。

一、通常意义上讲的时间戳timestamp，均是Unix时间(Unix time)。为啥叫UNIX TIME？因为起源于Unix系统。它的计量方式是：自 1970 年 1 月 1 日（00:00:00 GMT）以来的秒数。

重点注意的地方就在这里，如果是秒数，就是10位；而如果是毫秒数，就是13位。

秒和毫秒的进制是1000，所以开头所讲转化的时候除以1000，就是这个道理。

二、而不同编程语言、系统、工具，对于timestamp的默认处理方法可能存在差异，以及不同场景下对时间精度的不同要求，就是导致可能出现不同
长度时间戳的根源。

例如，开头提到的MySQL的FROM_UNIXTIME函数默认处理的是10位的时间戳；

在Java中，通常使用System.currentTimeMillis()方法来获取当前时间的13位时间戳；

在JavaScript中，时间戳是一个表示自1970年1月1日(UTC)以来毫秒数的数字。可以使用Date对象来获取和处理时间戳。

拿笔者此次遇到的问题举例：

开始的时候查询不出正常的结果（返回的结果显示为空），没有特别留意。但后面想想肯定哪里不对。

数了一下时间戳长度，发现了原因所在。

查了一下格式，也印证了这个问题：

SHOW COLUMNS FROM tech_innovation.t_count_software_copyright;

对症下药，笔者的查询结果便正确了。查询代码：

SELECT update_time, FROM_UNIXTIME((update_time/1000), '%Y-%m-%d') AS update_time_formatted, software_name, completer
FROM tech_innovation.t_count_software_copyright
WHERE FROM_UNIXTIME((update_time/1000), '%Y-%m') = '2024-08';

结果显示正常：