MySQL 的 DATETIME 和 TIMESTAMP 有什么区别？时区变化会影响查询结果吗？

下面是一段教学用的模拟面试。

🧑‍💻 面试官：DATETIME 和 TIMESTAMP 怎么选？

🙋‍♂️ 我：TIMESTAMP 带时区，DATETIME 不带时区。

🧑‍💻 面试官：TIMESTAMP 真的把“亚洲上海”这个时区名保存在字段里了吗？

🙋‍♂️ 我：它会按会话时区转换，但没有保存原来的时区名。

🧑‍💻 面试官：订单支付时刻和“明年某地每天早上九点开课”，你会用同一种时间含义吗？

先分清你在保存「一个确定时刻」，还是「当地日历上的时间」。时区转换能力，不能代替时间含义的设计。

面试速答（60 秒版）

MySQL 的 DATETIME 主要保存日期时间字段值，不自动根据会话时区转换；TIMESTAMP 则按会话时区解释写入值，转换为 UTC 保存，读取时再转到当前会话时区。

因此，同一个 TIMESTAMP 在不同时区会话中可能显示不同时间，但表示的时刻相同。它也没有保存原始时区名称，不能简称为“字段里带一个时区”。

在 MySQL 8.4 中，DATETIME 的日期范围远大于 TIMESTAMP，后者仍有 2038 年范围限制。两者都可以使用小数秒精度。

实际选型先看语义和范围，再统一应用、连接和数据库的时区约定。确定发生的支付时刻与未来当地时间安排不同；如果使用 DATETIME 保存 UTC，也需要明确这是应用约定，不是类型自动保证。

Q287 面试速答总览：+08 写12:00，DATETIME保留12，TIMESTAMP内部UTC04再在+08读12。

知识点详解：同一个 12:00，切换时区以后为什么会变？

先做一个能推演的实验

咱们假设在会话时区 +08:00 中，把 2026-10-04 12:00:00 同时写进两个字段：

CREATE TEMPORARY TABLE time_demo (
  wall_time DATETIME(6),
  event_time TIMESTAMP(6)
);

SET time_zone = '+08:00';
INSERT INTO time_demo VALUES
  ('2026-10-04 12:00:00', '2026-10-04 12:00:00');

SET time_zone = '+00:00';
SELECT wall_time, event_time FROM time_demo;

在 MySQL 8.4 的这组条件下，wall_time 仍显示 12:00:00，event_time 会显示 04:00:00。这里是根据官方语义给出的可复现实验预期，本轮没有连接实际 MySQL 执行。

原因是：DATETIME 保存的日历值没有随会话时区转换；TIMESTAMP 写入时把 +08:00 的 12 点换算成 UTC 4 点，读取时 +00:00 会话再显示为 4 点。

时间不是被随机改掉了，发生变化的是同一个时刻的显示方式。实验使用固定偏移，避免命名时区需要加载时区表的额外条件。

Q287 知识点示意：+08写入、+00读出，TIMESTAMP读04，DATETIME读12；不将会话转换扩大成完全无时区影响。

类型不会替你保存所有时间信息

TIMESTAMP 不保存“原来的用户位于哪个城市”。读取显示由当前会话时区决定，所以需要保留用户时区时，应另外保存明确的时区标识等信息。

DATETIME 也不是天然的 UTC。应用可以约定它保存 UTC 日历值，但数据库不会看到字段名叫 created_at 就自动替你执行转换。

如果一个连接按上海时间写入，另一个连接却把同样的无时区字符串按 UTC 理解，就可能让实际时刻偏差八小时。这属于输入、连接与应用约定不一致，不是一个类型名字能解决的问题。

2038 年限制和小数秒，是另外两个条件

MySQL 8.4 的 TIMESTAMP 范围大致从 1970 年初到 2038 年 1 月；DATETIME 的日期范围为 1000 年到 9999 年。边界具体值见 MySQL 8.4 官方日期时间文档。

这与 Unix 时间戳在其他数据库、语言中能表示多大范围，是不同问题。不能因为某个语言支持 64 位时间戳，就推导当前 MySQL TIMESTAMP 自动支持 2100 年。

两种类型都可以配置 0 到 6 位小数秒。字段声明、驱动解析和应用序列化还需要一起检查，避免数据库保留了微秒，接口却只发出秒。

支付时间与未来课程安排，应该怎样建模？

支付已经发生，通常要记录一个可跨地区比较的确定时刻，再按用户所在时区显示。

未来“当地每天九点开课”则需要当地时间和地点的时区规则。夏令时、规则变化会影响未来对应的 UTC 时刻，不能只留下一个没有地区信息的数字就声称完整保存了需求。

日期类型的选择只是其中一步。还要明确接口是否带偏移、连接时区怎样初始化、是否记录原始地区信息，以及统计报表按哪个时区划分一天。

Q287 知识点示意：同一时刻与当地每周9点区分，保留时区规则；无伦敦/纽约固定偏移错误。

面试官继续追问

DATETIME 是不是绝对不受时区影响？

它自身不按会话时区执行这种自动转换，但输入函数、驱动和应用可以先做转换。例如应用把 Date 转成字符串的过程仍可能受时区约定影响。

TIMESTAMP 的自动更新时间，是不是它独有的优势？

不要沿用旧版印象。现代 MySQL 的 DATETIME 也能配置相应默认值和自动更新行为；要区分字段初始化机制与时区存储语义。

面试速记卡

DATETIME：保存日历值，不自动随会话时区转换。

TIMESTAMP：按会话时区写入、UTC 保存、按会话时区读出。

时区信息：TIMESTAMP 不保留原始时区名称。

版本范围：MySQL 8.4 的 TIMESTAMP 仍有 2038 年限制。

选型：先定时刻或当地时间语义，再定范围、精度与时区约定。