元宿six先聊一个我经常在技术群里看到的场景：MySQL 里存日期，有的人用 varchar，有的人用 date，有的人用 timestamp，结果每次做报表、做区间查询、做跨系统对接的时候，光搞日期格式就折腾半天。尤其是遇到“字符转日期”、“日期转时间戳”这种需求，写出来的 SQL 五花八门——有人用 str_to_date，有人用 cast，有人直接拿字符串和日期列做比较，最后要么查出空数据，要么直接报错 Incorrect datetime value。
这篇文章我不打算罗列 API 文档，只讲实际干活时最常用的几组转换方案，以及背后的原理和踩坑点。内容围绕一个主线展开：字符、DATE、TIMESTAMP 三者怎么互相转，以及转换过程中的格式、精度、时区这些坑怎么避。不管是刚接触 MySQL 的新手，还是被日期转换折磨过的老手，这篇文章应该都能给你一些参考。
1. 先搞清楚基础概念：DATE、DATETIME、TIMESTAMP 到底差在哪
很多转换报错，根子不在“怎么转”，而在“转到哪”。先把目标类型搞清楚，后面所有转换逻辑就顺了。
1.1 三者的本质区别
MySQL 里跟日期时间相关的类型有好几个，但业务里最常打交道的就是 DATE、DATETIME、TIMESTAMP 这三个。它们的区别不只是名字，而是底层存储逻辑完全不同。
DATE：只存日期，格式YYYY-MM-DD，范围是1000-01-01到9999-12-31，占用 3 个字节。DATETIME：存日期加时间，格式YYYY-MM-DD HH:MM:SS，范围同样是1000-01-01 00:00:00到9999-12-31 23:59:59，占用 8 个字节。它不依赖时区，存进去是什么就是什么。TIMESTAMP：字面意思是“时间戳”，但 MySQL 里的TIMESTAMP类型并不是整数形式的 Unix 时间戳，它仍然是YYYY-MM-DD HH:MM:SS这种展示格式。不过底层存储是 UTC 时间，展示的时候会根据数据库、连接或会话的时区设置自动转换。
注意：很多新手以为
TIMESTAMP就是1970 年以来的秒数，其实在 MySQL 里不完全是这样。真正存“秒数”的是UNIX_TIMESTAMP()函数的结果，而TIMESTAMP类型是一个有时区概念的日期时间类型。
TIMESTAMP 的范围是 1970-01-01 00:00:01 UTC 到 2038-01-19 03:14:07 UTC，这正是 32 位整数能表达的时间上限，也就是常说的“2038 年问题”。如果你的业务需要存 2038 年以后的日期，TIMESTAMP 类型直接不能用，必须选 DATETIME。
1.2 为什么 TIMESTAMP 是“烫手山芋”
TIMESTAMP 最坑人的地方在于时区隐式转换。举一个我实际遇到过的例子：
数据库服务器的 time_zone 设置是 +08:00，我往一张表里插入一个 TIMESTAMP 列，传入的值是 2024-06-01 12:00:00。表面上存进去了，但如果你把会话时区改成 +00:00，再去查这条记录，你会发现它变成了 2024-06-01 04:00:00。
这就是 TIMESTAMP 的底层逻辑：存储时转成 UTC，查询时再按当前时区转回来。如果你的应用层和数据库时区不一致，或者多套环境之间时区漂移，就会出现“数据对不上”的诡异问题。
而 DATETIME 没这个问题，它不关心时区，你怎么存就怎么取。所以我的一个个人习惯是：除非有明确需求要跟随时区变化，否则业务表一律用 DATETIME，TIMESTAMP 只在需要自动初始化或自动更新的场景下用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 字符转 DATE：最常用的三种写法
回到正题，字符转 DATE 是日常开发里出现频率最高的需求。前端传一个 2024-06-01，接口层存进 MySQL，或者从 Excel 导入一批日期字符串，都需要这步转换。
2.1 STR_TO_DATE：最灵活、最推荐
STR_TO_DATE(str, format) 是 MySQL 提供的字符串解析函数，作用和 Oracle 的 TO_DATE 类似。它按你指定的格式去解析字符串，返回对应的日期或时间。
sql复制SELECT STR_TO_DATE('2024-06-01', '%Y-%m-%d');
-- 结果：2024-06-01
SELECT STR_TO_DATE('2024/06/01', '%Y/%m/%d');
-- 结果：2024-06-01
SELECT STR_TO_DATE('2024-06-01 14:30:00', '%Y-%m-%d %H:%i:%s');
-- 结果：2024-06-01 14:30:00
这里有几个格式符要记牢：
%Y：四位年份%y：两位年份%m：两位月份%c：月份，无前导零%d：两位日%e：日，无前导零%H：24 小时制，两位%k：24 小时制，无前导零%i：分钟，两位%s：秒，两位%p：AM 或 PM，配合%h（12 小时制）用
STR_TO_DATE 的优势是解析能力强，字符串里带不带前导零、分隔符是横线还是斜杠，都能通过格式串控制。它返回的值可以隐式转为 DATE、DATETIME 或 TIME，取决于格式串里包含哪些部分。
重要提醒：
STR_TO_DATE的结果类型不是固定DATE，而是根据格式串推断。只含年月日就返回DATE，含时分秒就返回DATETIME。如果业务上明确要DATE类型，建议再套一层CAST，避免类型推断带来的隐性差异。
2.2 CAST 和 CONVERT：标准 SQL 写法
如果你的字符串格式就是标准的 YYYY-MM-DD HH:MM:SS，那最简单的方式是直接用 CAST 或 CONVERT，连格式串都不用写。
sql复制SELECT CAST('2024-06-01' AS DATE);
-- 结果：2024-06-01
SELECT CAST('2024-06-01 14:30:00' AS DATETIME);
-- 结果：2024-06-01 14:30:00
SELECT CONVERT('2024-06-01', DATE);
-- 结果：2024-06-01
CAST 和 CONVERT 本质一样，只是语法位置不同。它们的限制也很明显：字符串必须符合 MySQL 默认的日期格式，YYYY-MM-DD 或 YYYY-MM-DD HH:MM:SS，其他格式（比如 2024/06/01）直接报错或返回 NULL。
sql复制SELECT CAST('2024/06/01' AS DATE);
-- 结果：NULL，并有 Warning
所以 CAST 适合格式规整、来源可控的场景；STR_TO_DATE 适合格式多样的场景。我一般优先试 STR_TO_DATE，因为它的容错空间更大。
2.3 隐式转换：方便但危险
MySQL 里还有一个很隐蔽的转换路径：隐式转换。当你拿字符串和日期列做比较时，MySQL 会自动尝试把字符串转成日期。
sql复制SELECT * FROM orders WHERE create_time = '2024-06-01';
这段 SQL 在 create_time 是 DATETIME 列时能正常执行，因为 MySQL 把字符串转成了日期。但如果字符串格式不标准，或者列本身是 VARCHAR，那结果就完全不可控了。
更危险的是字符串和数字混用。比如一个查询条件写成 WHERE date_col = 20240601，MySQL 会把数字转成字符串再转日期，如果转换失败就静默返回空结果，然后你的报表就莫名少了数据。排查半天才发现是类型问题。
我的建议是：不要依赖隐式转换，所有日期比较都显式用
STR_TO_DATE或CAST转换为同一类型。查询速度也更快，因为显式转换之后列上的索引还可能在；隐式转换经常导致索引失效，这个在慢查询排查里非常常见。
3. 字符转 TIMESTAMP：精度、时区与毫秒的坑
字符串转 TIMESTAMP 看着和转 DATETIME 差不多，但实际踩坑更多。这里把常见场景拆开讲。
3.1 字符串到 TIMESTAMP 的标准流程
先把字符串解析成 DATETIME，再让 MySQL 按当前时区把它转成 TIMESTAMP 存储。
sql复制SELECT CAST('2024-06-01 14:30:00' AS TIMESTAMP);
-- 或者
SELECT CONVERT('2024-06-01 14:30:00', TIMESTAMP);
-- 或者
SELECT TIMESTAMP('2024-06-01 14:30:00');
这三条都可行，但 TIMESTAMP('2024-06-01 14:30:00') 的写法本质是把字符串转成 DATETIME，再用 CAST 转 TIMESTAMP，效果是一样的。如果字符串格式不规整，还是得先 STR_TO_DATE 一下：
sql复制SELECT CAST(STR_TO_DATE('2024/06/01 14:30:00', '%Y/%m/%d %H:%i:%s') AS TIMESTAMP);
这个写法我看很多人绕来绕去，其实就是两步：解析、转型。拆开写反而更清晰。
3.2 毫秒精度与四舍五入：MySQL 8.0 的真实行为
现在很多业务系统用 Java 的 Timestamp 对象，它默认带毫秒，比如 2024-06-01 14:30:00.123。这种数据写入 MySQL 时，有个高频问题：
Java Timestamp 的毫秒写入 MySQL 8.0 会四舍五入吗？
答案是：取决于目标列的类型和精度定义。
- 如果列是
DATETIME或TIMESTAMP，没带小数秒精度，MySQL 会先对小数秒做四舍五入，再丢弃小数部分。比如14:30:00.500会变成14:30:01，.499变成14:30:00。 - 如果列定义了精度，比如
DATETIME(3)或TIMESTAMP(3)，那毫秒会完整保留三位小数，不会丢精度。 - 如果你的列是
DATETIME(6)，那存进去的是微秒精度，毫秒只是其中的一部分。
这个“四舍五入”行为在 MySQL 8.0 里表现得特别明显，因为 8.0 对时间类型做了很多底层重写。早期版本可能直接截断（TRUNCATE），但在 8.0 里用的是 四舍五入（ROUND）。
sql复制CREATE TABLE t1 (
dt DATETIME,
d3 DATETIME(3),
d6 DATETIME(6)
);
INSERT INTO t1 VALUES
('2024-06-01 14:30:00.500'),
('2024-06-01 14:30:00.500'),
('2024-06-01 14:30:00.500');
SELECT * FROM t1;
-- dt : 2024-06-01 14:30:01 （四舍五入）
-- d3 : 2024-06-01 14:30:00.500 （保留毫秒）
-- d6 : 2024-06-01 14:30:00.500000 （微秒，末尾补零）
所以如果你的应用对“时间点”的一致性要求很高（比如金融交易流水），一定要把列精度定义到 (3) 或 (6)，不要用默认的 DATETIME，否则数据在写入环节就可能被“偷偷改掉”。
如果历史表已经建成不带精度的
DATETIME，数据写进去被四舍五入了，只能通过应用层先对毫秒做向下取整，再入库，或者改表结构。改表结构在大表上代价很高，所以设计阶段就定好精度是成本最低的做法。
3.3 时区问题：TIMESTAMP 比 DATETIME 更“妖”
TIMESTAMP 的时区转换问题在前文提到过，实际做数据迁移或跨地域部署时，这个问题会非常明显。
举个真实案例：有个系统原来部署在华东，数据库时区是 +08:00，业务表都是 DATETIME 类型。后来上云，云厂商的数据库默认时区是 +00:00，导入旧数据后，所有时间看起来都“少了 8 小时”。这就是因为原来的 DATETIME 是本地时间，导入后依然按本地时间展示，但应用层如果做了一次 TIMESTAMP 转换，就会按新的会话时区再转一次，导致偏差。
检查当前时区：
sql复制SELECT @@global.time_zone, @@session.time_zone;
常见的解决方式有几种：
- 锁死数据库时区为
+08:00，应用层不感知时区，DATETIME和TIMESTAMP都用本地时间。 - 所有时间统一存 UTC，应用层展示时转本地时间。这种情况下
TIMESTAMP类型更合适，因为它在连接时区变化时会自动跟着转。 - 混合使用，但转
TIMESTAMP时显式指定时区，比如用CONVERT_TZ函数。
sql复制SELECT CONVERT_TZ('2024-06-01 14:30:00', '+08:00', '+00:00');
-- 结果：2024-06-01 06:30:00
个人建议：团队小、业务简单，直接用
DATETIME存本地时间；团队大、多地域部署，统一 UTC +TIMESTAMP或DATETIME按约定存储。最怕的是没有约定，各个系统各存各的，数据打通时全是时间换算的锅。
4. 反向转换：DATE 和 TIMESTAMP 转成字符
“字符转日期”是一半需求，另一半是“日期转字符”——导出报表、拼接文件名、生成前端展示字段，都得把日期变成字符串。
4.1 DATE_FORMAT：字符输出的大杀器
DATE_FORMAT(date, format) 是把日期时间转成指定格式字符串的核心函数。它和 STR_TO_DATE 正好是互逆操作。
sql复制SELECT DATE_FORMAT('2024-06-01 14:30:00', '%Y-%m-%d');
-- 结果：2024-06-01
SELECT DATE_FORMAT('2024-06-01 14:30:00', '%Y-%m-%d %H:%i:%s');
-- 结果：2024-06-01 14:30:00
SELECT DATE_FORMAT('2024-06-01 14:30:00', '%Y年%m月%d日');
-- 结果：2024年06月01日
SELECT DATE_FORMAT('2024-06-01 14:30:00', '%H:%i:%s');
-- 结果：14:30:00
需要留意的是，DATE_FORMAT 支持中文输出和中文日期格式，这在生成月度报表标题时很实用，比如：
sql复制SELECT DATE_FORMAT(NOW(), '%Y年%m月数据报表');
-- 结果：2024年06月数据报表
%Y 和 %y 的差异也要注意，一个四位年份，一个两位年份。跨世纪数据如果用了 %y，很可能在展示层被误读。
4.2 UNIX 时间戳和 FROM_UNIXTIME：跨系统对接的桥梁
很多外部系统（比如 Java、Python 后端或第三方 API）喜欢用 Unix 时间戳表示时间，MySQL 也提供了两个专门的函数来对接。
sql复制-- 日期时间转 Unix 时间戳（秒）
SELECT UNIX_TIMESTAMP('2024-06-01 14:30:00');
-- 结果：1717146600
-- Unix 时间戳（秒）转日期时间
SELECT FROM_UNIXTIME(1717146600);
-- 结果：2024-06-01 14:30:00
-- 转成带格式的字符串
SELECT FROM_UNIXTIME(1717146600, '%Y-%m-%d %H:%i:%s');
-- 结果：2024-06-01 14:30:00
UNIX_TIMESTAMP 的返回单位是秒，不是毫秒。现在很多接口传的是毫秒级时间戳（比如 Java 的 System.currentTimeMillis()），如果直接丢给 FROM_UNIXTIME，会得出一个离谱的时间。
处理毫秒级时间戳有两个思路：
- 除以 1000 得到秒，再
FROM_UNIXTIME：
sql复制SELECT FROM_UNIXTIME(1717146600123 / 1000);
-- 结果：2024-06-01 14:30:00.1230
- 用 MySQL 8.0 的浮点支持，直接传带小数的秒：
sql复制SELECT FROM_UNIXTIME(1717146600.123);
-- 结果：2024-06-01 14:30:00.1230
注意
FROM_UNIXTIME返回的结果默认带 6 位小数秒。如果你只想精确到秒，格式化串里不要带小数，或者直接CAST成DATETIME截断。
还有一个和 DATE_FORMAT 类似但作用域不同的函数：TIME_FORMAT，它只处理时间部分。如果某个字段是 TIME 类型，想输出 14:30:00 或 02:30 PM，直接 TIME_FORMAT 更合适。
sql复制SELECT TIME_FORMAT('14:30:00', '%h:%i %p');
-- 结果：02:30 PM
4.3 24 小时制和 12 小时制：最容易看走眼的地方
日期格式化里最容易犯的错，是把 %H 和 %h 搞混。
%H：24 小时制，00到23。%h：12 小时制，01到12，需要配合%p（AM/PM）使用。
我遇到过不止一次，后台导出报表，时间列全部变成 12 小时制，下午 2 点显示成 02:00，而且没有 AM/PM 标记，数据直接没法看。排查了半天，就是导出 SQL 里用了 %h 而不是 %H。
建议：后端存储和接口层统一用 24 小时制，前端展示层按用户本地习惯再格式化。 这样整个数据链路只有一次转换边界，不容易乱。
5. 高频报错与排查技巧实录
日期转换的报错信息往往让人一头雾水，这里整理几个我实际遇到过的典型问题。
5.1 常见报错速查表
| 报错或异常现象 | 常见原因 | 解决方式 |
|---|---|---|
Incorrect datetime value: '2024-6-1' |
月份/日期没补前导零 | 用 STR_TO_DATE('2024-6-1', '%Y-%c-%e') 或应用层补零 |
Data truncation: Incorrect date value |
字符串格式和预期格式不匹配 | 检查格式串，确认分隔符、前导零、24/12 小时制 |
| 返回 NULL，但不报错 | CAST 无法解析非标格式 |
改用 STR_TO_DATE 并指定格式 |
| 查询结果少了 8 小时 | 时区不一致，TIMESTAMP 被自动转换 |
检查 time_zone 设置，统一应用层和数据库时区 |
| 毫秒被“篡改”成下一秒 | DATETIME 或 TIMESTAMP 列没有定义小数秒精度 |
建表时用 DATETIME(3)/TIMESTAMP(3) 或应用层先舍入 |
插入合法日期却提示 Out of range |
年份超过了 TIMESTAMP 的 2038 年上限 |
改列类型为 DATETIME |
| 排序结果看起来不对 | 列是 VARCHAR，按字符串排序而非日期排序 |
显式 CAST 成 DATE 再排序，或修改列类型 |
5.2 日期比较中“反直觉”的坑
有一个场景坑了很多人：按日期范围查“某天的数据”。
sql复制-- 错误示范
SELECT * FROM orders
WHERE create_time = '2024-06-01';
如果 create_time 是 DATETIME，这条 SQL 查出来的只有 2024-06-01 00:00:00 这一秒的数据，其余时间的数据全丢了。正确写法是：
sql复制-- 正确写法一
SELECT * FROM orders
WHERE create_time >= '2024-06-01 00:00:00'
AND create_time < '2024-06-02 00:00:00';
-- 正确写法二
SELECT * FROM orders
WHERE DATE(create_time) = '2024-06-01';
写法二更好理解，但 DATE(create_time) 会让 create_time 上的索引失效。数据量大的时候，还是推荐范围匹配写法。
还有一种比较常见的坑：日期区间参数类型是字符串，但格式是 2024-06-01 00:00:00.000。这种带毫秒的字符串如果直接和 DATETIME 列比较，MySQL 的转换规则是按需截断，通常没问题，但效率不高。建议先用 STR_TO_DATE 转一次，再参与比较。
5.3 一个综合实战：统计每日订单量
把上面提到的转换能力串起来，看一个实际报表场景：统计每天订单量，并按指定格式输出。
sql复制SELECT
DATE_FORMAT(create_time, '%Y-%m-%d') AS order_day,
COUNT(*) AS order_cnt
FROM orders
WHERE create_time >= STR_TO_DATE('2024-06-01', '%Y-%m-%d')
AND create_time < STR_TO_DATE('2024-07-01', '%Y-%m-%d')
GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d')
ORDER BY order_day;
这里有几个细节：
- 入参是字符串
2024-06-01，主动用STR_TO_DATE转成日期，避免隐式转换带来的性能损耗。 GROUP BY使用DATE_FORMAT的结果，输出的是字符串，适合直接丢给前端展示。- 如果数据量特别大，这个查询的
GROUP BY无法走索引，更优方案是GROUP BY create_time在内存里按天聚合，但这要看具体数据量和 MySQL 版本。早期版本对GROUP BY的表达式支持有限，直接按表达式分组也 OK。
5.4 关于 MySQL 8.0 的新变化
MySQL 8.0 对日期时间类型做了一些调整，和转换相关的有几点值得了解。
第一，8.0 的隐式转换规则更严格。比如用字符串和日期列比较时，如果字符串格式不标准，以前可能静默返回 NULL，现在会直接报错。
第二，8.0.19 之后引入了 CAST(... AT TIME ZONE ...),允许在 SQL 层面显式处理时区转换。如果你的业务涉及多时区，这个语法很实用。
sql复制SELECT CAST('2024-06-01 14:30:00' AT TIME ZONE '+08:00' AS DATETIME);
不过这属于进阶用法，日常业务用到的场景不多。我提出来是希望大家知道有这么个东西，真遇到时区问题的时候能想起来。
第三，8.0 对 TIMESTAMP 的保存做了底层优化，但对外表现基本一致。也就是说，你不需要因为版本升级而修改现有的转换逻辑。
6. 常用函数速查表与个人心得
最后整理一份速查表，放在手边随手能翻到。
6.1 核心转换函数速查
| 转换方向 | 推荐函数 | 示例 |
|---|---|---|
| 字符串 -> DATE | STR_TO_DATE |
STR_TO_DATE('2024/06/01', '%Y/%m/%d') |
| 字符串 -> DATETIME | STR_TO_DATE |
STR_TO_DATE('2024-06-01 14:30:00', '%Y-%m-%d %H:%i:%s') |
| 字符串 -> TIMESTAMP | CAST(STR_TO_DATE(...) AS TIMESTAMP) |
CAST(STR_TO_DATE('2024-06-01 14:30:00', '%Y-%m-%d %H:%i:%s') AS TIMESTAMP) |
| DATE/DATETIME -> 字符串 | DATE_FORMAT |
DATE_FORMAT(NOW(), '%Y-%m-%d') |
| DATETIME -> Unix 秒 | UNIX_TIMESTAMP |
UNIX_TIMESTAMP('2024-06-01 14:30:00') |
| Unix 秒 -> DATETIME | FROM_UNIXTIME |
FROM_UNIXTIME(1717146600) |
| 字符串 -> 日期时间（格式规整时） | CAST / CONVERT |
CAST('2024-06-01' AS DATE) |
| 日期字符串解析（支持多格式） | STR_TO_DATE |
灵活指定格式串 |
关于 TIMESTAMP 和 DATETIME 的选择，再强调一遍个人观点：
- 存储纯业务时间（下单时间、创建时间、更新时间），
DATETIME更稳。 - 跨时区系统，建议统一 UTC，存储时用
TIMESTAMP或约定DATETIME+ 时区后缀。 - 只有需要自动初始化或自动更新的列，才用
TIMESTAMP的DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP特性。
6.2 我踩过的几个坑，最后总结一下
日期时间转换的坑，十次有八次出在格式、时区、精度这三件事上。我踩过最深刻的一个坑是在做数据迁移时，源库的某个 VARCHAR 字段里存的日期格式五花八门，有 2024-06-01、2024/6/1、01-JUN-24 混在一起。当时图省事，直接用 CAST 去转，结果大量行变成 NULL，数据修复花了一整天。
后来我把所有格式先归一化，写了一个统一的转换函数，业务代码里所有日期入库都走这个入口：
sql复制STR_TO_DATE(REPLACE(input_str, '/', '-'), '%Y-%m-%d')
虽然不完美，但对绝大多数场景够用。如果你的数据来源更乱，建议先做一次 SQL 检查，把每个格式的样本量统计出来，再决定转换规则。
另一个让我记忆犹新的场景是时区。有一次用户投诉某个功能的时间显示差了 8 小时，排查后发现数据库连接 URL 里设了 serverTimezone=UTC，但应用服务器本地时区是东八区。Java 侧写入的时候，Timestamp 被转了一次，数据库又按本地时区转了一次，双重转换直接把数据搞偏移了。最后是统一连接串时区、统一数据库时区，问题才彻底解决。这类问题不会在测试环境暴露，因为单机测试时区一致，一上生产多环境就炸。
所以如果你正在设计表结构，或者正在排查日期相关的数据异常，先问自己三个问题：这个字段到底是什么类型？应用的时区设置是什么？入库前有没有经过任何一层隐式转换？ 把这三个问题理顺了，日期转换这个事就算掌握了大半。
最后再分享一个实用的小技巧：排查日期转换问题时，先别急着改代码，执行一下 SELECT STR_TO_DATE('你的数据', '%Y-%m-%d') 看看能不能解析成功，再用二分法逐个字段排除。这个办法帮我定位过不少看似复杂的“灵异事件”。