云海天狼作为一个常年跟 MySQL 打交道的人，我几乎每周都会在技术群里看到类似的问题：“为什么我查出来的日期不对？”“为什么我传进去的是字符串，存到库里就变了？”“为什么同一个时间戳，在测试库和线上库查出来不一样？”说来说去，很多人最后都会绕到一个点上——MySQL 里 DATE、TIMESTAMP 和字符串/数字之间的转换，到底怎么搞才不出错。
说实话，这个话题看起来基础，但坑是真的多。尤其是从字符转到 DATE 和 TIMESTAMP，再转回去，中间涉及格式化规则、隐式转换陷阱、时区处理，还有 MySQL 8.0 之后新增的语法。很多老手在没仔细验证的情况下都会踩雷。这篇文章我不打算抄文档，就结合我自己的实操经验，把字符、DATE、TIMESTAMP、UNIX 时间戳之间互转的细节、坑点和验证过程一次讲清楚，希望能帮你少走点弯路。
1. 先搞懂 MySQL 里的三兄弟：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，范围同上，占用 8 字节（5.6.4 之前是 8 字节，之后支持小数秒时可能更多）。 - TIMESTAMP：存的是“从 1970-01-01 00:00:00 UTC 到当前时间的秒数”，显示时根据会话时区换算成本地时间，范围从
1970-01-01 00:00:01 UTC到2038-01-19 03:14:07 UTC，占用 4 字节。
这里最容易被忽视的就是 TIMESTAMP 的“UTC 秒数 + 会话时区换算”机制。也就是说，同一个 TIMESTAMP 值，在不同时区的客户端连接下，执行 SELECT 查出来可能是不一样的“本地时间”。
我在实际项目中就遇到过这样的问题：测试环境服务器时区是 CST（中国标准时间），而线上数据库的
time_zone参数被误设为+00:00，结果应用层同一段代码，在测试环境读到的时间比线上快了 8 小时。排查到最后，发现不是代码问题，而是 TIMESTAMP 类型本身就会跟随时区变化。
1.2 字符串与数字之间，先要辨别“伪日期”字符串
所谓“伪日期”字符串，就是长得像日期但不是标准格式的文本，比如 2024/01/15、2024年1月5日、15-JAN-24 等。这些字符串在 MySQL 中可以直接写入日期字段，但前提是它们能被 MySQL 的“宽松解析器”识别。
MySQL 默认情况下对字符串转日期的容忍度比较高，但不是所有格式都能识别。比如 '2024-1-5'、'2024/01/15' 是可以被直接识别的，但 '15/01/2024' 这种日/月/年格式就没法识别，插入时会报错或变成 0000-00-00。
查了一下官方文档，MySQL 对日期字符串的识别规则是：年份在最前面，然后是月份、日期、小时、分钟、秒，中间可以用 -、/、@、空格等符号分隔。月份和日期可以是 1 位或 2 位数字。这个宽松解析能省很多事，但也容易埋雷。
1.3 一张表看懂三种类型的核心对比
| 特性 | DATE | DATETIME | TIMESTAMP |
|---|---|---|---|
| 存储内容 | 日期 | 日期+时间 | UTC 秒数 |
| 显示格式 | YYYY-MM-DD | YYYY-MM-DD HH:MM:SS | 根据时区显示 |
| 存储大小 | 3 字节 | 8 字节 | 4 字节 |
| 支持范围 | 1000-9999 | 1000-9999 | 1970-2038 |
| 受时区影响 | 否 | 否 | 是 |
| 自动初始化 | 不支持 | 支持（需配置） | 支持（需配置） |
| 默认值 | 支持（8.0+可用表达式） | 支持（8.0+可用表达式） | 支持（8.0+可用表达式） |
这个表格建议收藏。它解释了很多“为什么”的问题。比如为什么 TIMESTAMP 不能用 9999-12-31 这种远期日期？因为 2038 年问题（2038 年 1 月 19 日之后，32 位整数的秒数会溢出）。为什么 TIMESTAMP 在存储时比 DATETIME 省空间？因为它存的是秒数而不是文本。为什么两个库查出来的同一行数据时间不一致？因为时区设置不同。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 字符转 DATE 和 TIMESTAMP：核心函数与格式化规则
说完基础类型，正式进入正题。把字符串转成日期类型，最常用的函数是 STR_TO_DATE()、CAST()、CONVERT()，以及 MySQL 8.0 引入的 CAST(... AT TIME ZONE) 新语法。它们各自有适用场景，也有各自的坑。
2.1 STR_TO_DATE：自由格式解析的瑞士军刀
STR_TO_DATE(str, format) 是最灵活的转换函数，它允许你按照自定义的格式模板解析字符串。格式符和 DATE_FORMAT() 是同一套体系，可以对照着记忆。
格式符常用几个：
%Y：四位数年份；%y：两位数年份%m：月份，01-12；%c：月份，1-12 不带前导零%d：日，01-31；%e：日，1-31 不带前导零%H：小时，00-23；%h：小时，01-12%i：分钟，00-59%s：秒，00-59%f：微秒，000000-999999%p：AM 或 PM%b：英文月份缩写，如 Jan；%M：英文月份全称，如 January
核心用法示例：
sql复制-- 将字符串解析为 DATE 类型
SELECT STR_TO_DATE('2024-08-15', '%Y-%m-%d');
-- 输出：2024-08-15
-- 将字符串解析为 DATETIME 类型
SELECT STR_TO_DATE('2024-08-15 14:30:00', '%Y-%m-%d %H:%i:%s');
-- 输出：2024-08-15 14:30:00
-- 解析带斜杠的日期
SELECT STR_TO_DATE('2024/08/15', '%Y/%m/%d');
-- 输出：2024-08-15
-- 解析带中文格式的日期
SELECT STR_TO_DATE('2024年08月15日', '%Y年%m月%d日');
-- 输出：2024-08-15
这里有几个容易踩的坑：
第一，格式符必须和字符串严格对应。比如字符串是 '2024-8-5'，你用 '%Y-%m-%d' 解析没问题，但如果你写成 '%Y-%c-%e' 也是可以的，如果用 '%Y-%M-%D' 就会失败，因为 %M 是英文月份，%D 是带序数词的