问题点在于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';
结果显示正常：
