核心思路是将13位毫秒级时间戳除以1000转为秒级，再用FROM_UNIXTIME转换为日期时间，最后通过DATE_FORMAT、DATE或CAST等函数格式化为YYYY-MM-DD。常用方法包括：①DATE_FORMAT(FROM_UNIXTIME(ts/1000), '%Y-%m-%d')；②DATE(FROM_UNIXTIME(ts/1000))；③CAST(FROM_UNIXTIME(ts/1000) AS DATE)。需注意字段应为BIGINT类型，避免精度丢失，并关注时区一致性问题。
MySQL中将13位时间戳转换为
YYYY-MM-DD格式，核心思路是先将毫秒级时间戳转换为秒级，然后利用MySQL内置的日期函数进行格式化。这通常通过除以1000来实现，接着使用
FROM_UNIXTIME将Unix时间戳转换为日期时间格式，最后用
DATE_FORMAT或
DATE函数提取并格式化为所需的日期字符串。
解决方案
在MySQL里，处理13位时间戳（通常是毫秒级的Unix时间戳）并将其转换为
YYYY-MM-DD格式，我们有几种实用的方法。这事儿听起来简单，但里头门道不少，特别是要确保数据的准确性。
方案一：使用FROM_UNIXTIME
和DATE_FORMAT
组合
这是最常见也最灵活的办法。13位时间戳比我们熟悉的10位时间戳（秒级）多出了三位，那多出来的就是毫秒。所以，第一步自然是把它变成秒级。
SELECT DATE_FORMAT(FROM_UNIXTIME(your_13_digit_timestamp_column / 1000), '%Y-%m-%d') AS formatted_date;
这里
your_13_digit_timestamp_column是你存放13位时间戳的字段。
FROM_UNIXTIME()函数会把Unix时间戳（秒级）转换成MySQL的日期时间格式，而
DATE_FORMAT()则能让你随心所欲地指定输出格式。
%Y-%m-%d正是我们需要的年-月-日的格式。我个人觉得这个方法是最稳妥的，因为它提供了完整的日期时间对象，后续如果还需要其他部分（比如小时分钟），也很容易扩展。
方案二：使用FROM_UNIXTIME
和DATE
函数
如果你只是纯粹想得到日期部分，而不需要关心具体的格式化字符串，
DATE()函数提供了一个更简洁的途径。它会直接从日期时间表达式中提取日期部分。
SELECT DATE(FROM_UNIXTIME(your_13_digit_timestamp_column / 1000)) AS extracted_date;
这个方案输出的日期格式默认也是
YYYY-MM-DD。对我来说，如果仅仅是需要日期本身，而不是一个特定格式的字符串，这个方法就显得更直接了。它省去了
%Y-%m-%d的指定，代码看起来更精炼。
方案三：使用FROM_UNIXTIME
配合CAST
或CONVERT
进行类型转换
虽然不如前两种常用，但通过显式类型转换也能达到目的。
CAST或
CONVERT可以将一个日期时间类型转换为
DATE类型，从而自动截断时间部分。
SELECT CAST(FROM_UNIXTIME(your_13_digit_timestamp_column / 1000) AS DATE) AS casted_date; -- 或者 SELECT CONVERT(FROM_UNIXTIME(your_13_digit_timestamp_column / 1000), DATE) AS converted_date;
这两种方式在功能上基本等同。我通常不会优先选择这个，因为它感觉上多了一层转换，但如果你习惯于这种显式的类型转换思维，它也是一个可行的选择。重要的是，无论哪种方案，核心都是那个
/ 1000，把毫秒变成秒，这是关键一步。
为什么我的时间戳是13位，而不是常见的10位？
这其实是个很常见的问题，我最近就在处理一个类似的数据源。简单来说，10位时间戳代表的是自Unix纪元（1970年1月1日00:00:00 UTC）以来经过的“秒数”，而13位时间戳则代表“毫秒数”。
很多编程语言和系统，尤其是Java（
System.currentTimeMillis()）和JavaScript（
Date.now()），默认获取到的就是毫秒级时间戳。它们需要更高的精度来记录事件发生的时间点，比如在处理高并发请求、微服务日志或者前端用户行为追踪时，秒级精度可能就不够用了。比如，同一秒内可能发生了好几个事件，毫秒级就能把它们区分开。所以，当你看到13位时间戳时，不用惊讶，它只是比你平时见到的更“精确”一点而已。理解这个差异，你就知道为什么在MySQL里需要除以1000了，因为MySQL的
FROM_UNIXTIME函数默认是处理秒级时间戳的。
在MySQL中处理时间戳时，常见的陷阱有哪些？
处理时间戳，尤其是从不同系统导入的数据，总会遇到一些意想不到的问题。我个人就踩过不少坑，有些是数据类型的问题，有些则是时区在捣鬼。
一个大坑是数据类型选择不当。如果你的13位时间戳字段在数据库里定义成了
INT，那它根本存不下这么大的数值，
INT通常只能存到21亿多，而13位时间戳早就超出了这个范围。正确的做法是使用
BIGINT来存储原始的13位时间戳。或者，如果你一开始就打算存储为日期时间格式，那就应该用
DATETIME或
TIMESTAMP类型。
另一个让我头疼的是时区问题。
FROM_UNIXTIME函数默认会根据MySQL服务器的当前时区来转换Unix时间戳。如果你的应用程序和数据库服务器的时区设置不一致，或者你的时间戳是UTC时间，而服务器是本地时间，那转换出来的日期就会有偏差。比如，一个UTC时间戳在服务器是东八区时，可能会被误认为早了八个小时。解决办法通常是确保所有系统都使用UTC时间戳，或者在查询时明确指定时区，比如使用
CONVERT_TZ函数。这块儿说实话，很容易让人抓狂，因为问题往往不是立即显现的。
还有就是精度丢失。虽然我们这里是为了得到
YYYY-MM-DD，但如果你需要保留毫秒精度，而仅仅将13位时间戳除以1000并存入
DATETIME字段，那么毫秒部分就丢失了。MySQL 5.6.4版本以后支持
DATETIME(FSP)和
TIMESTAMP(FSP)，其中
FSP可以指定小数秒的精度（最高到6位），比如
DATETIME(3)就可以存储到毫秒。但如果你的MySQL版本老旧，或者字段定义就是普通的
DATETIME，那毫秒精度就拜拜了。
除了日期格式转换，13位时间戳还能如何用于数据分析？
13位时间戳，虽然在存储时可能需要
BIGINT，但它在数据分析中简直是个宝藏。除了简单的日期格式转换，它能帮助我们做很多有意思的分析。
首先是时间序列分析。既然是时间戳，那自然可以用来观察数据随时间变化的趋势。比如，通过
FROM_UNIXTIME(timestamp_col / 1000)，我们可以轻松地按天、按周、按月甚至按小时来聚合数据，看看某个指标（比如销售额、用户活跃度）在不同时间段的表现。结合
DATE_FORMAT，你可以提取出星期几、月份、年份等维度，进行更细致的分析。
其次是计算时间间隔和持续时间。如果你有两个13位时间戳，比如一个事件的开始时间和结束时间，你可以将它们都转换为秒级时间戳，然后直接相减，得到事件持续的秒数。再通过
DATEDIFF()、
TIMESTAMPDIFF()这类函数，可以方便地计算两个日期之间的天数、小时数等。这在分析用户停留时长、订单处理时间等方面非常有用。
另外，它也是数据过滤和筛选的利器。比如，你想查询某个特定日期范围内的数据，可以直接将日期字符串转换为Unix时间戳，然后与你的13位时间戳字段（除以1000后）进行比较。
-- 查找2023年10月1日到2023年10月31日的数据
SELECT *
FROM your_table
WHERE your_13_digit_timestamp_column / 1000 BETWEEN UNIX_TIMESTAMP('2023-10-01 00:00:00') AND UNIX_TIMESTAMP('2023-10-31 23:59:59');这种基于时间戳的范围查询效率通常很高，特别是如果你的时间戳字段有索引的话。它比基于字符串日期的范围查询更可靠，也更不容易出错。总的来说，13位时间戳虽然在转换时多了一步除法，但它作为一种统一的时间表示方式，在数据分析和查询优化方面都提供了很大的灵活性。
