MySQL 中 DATETIME 和 TIMESTAMP 有什么区别？

简化版

DATETIME 保存字面日期时间，范围更大，不随时区自动转换；TIMESTAMP 保存时间戳语义，范围较小，会按连接时区进行转换，常用于记录创建和更新时间。

详细版

DATETIME 更像“日历上的某个日期时间”，例如 2026-07-29 10:00:00，存进去和取出来通常就是这个字面值。它适合生日、预约日期、业务发生日期等不希望被会话时区改变的场景。

TIMESTAMP 更像“某个绝对时间点”，MySQL 会按时区进行存取转换。写入时从当前会话时区转换为内部时间，读取时再转换为当前会话时区展示。它常用于 created_at、updated_at 等系统审计时间。

面试中要讲：时区行为、取值范围、存储大小和业务语义。跨时区系统尤其不能随便混用时间类型。

完整版教学

一、两者表达的时间语义不同

DATETIME 表示一个日期时间字面量，重点是“看到的日期时间”。TIMESTAMP 更强调一个绝对时间点，重点是“同一瞬间在不同时区如何展示”。

CREATE TABLE events (
  id BIGINT PRIMARY KEY,
  plan_time DATETIME,
  created_at TIMESTAMP
);

plan_time 可以表示用户约定的本地时间，created_at 可以表示记录创建的系统时间。

记忆钩子：DATETIME 像日历时间，TIMESTAMP 像时间点。

二、时区转换是最重要区别

TIMESTAMP 会受会话时区影响，DATETIME 通常不做时区转换。

示意：

会话时区 +08:00 写入 TIMESTAMP '2026-07-29 10:00:00'
内部按 UTC 时间点存储
会话时区 +00:00 读取时可能显示 '2026-07-29 02:00:00'

而 DATETIME '2026-07-29 10:00:00' 更像保存这个字面日期时间，换会话时区读取仍然是这个值。

这就是跨时区业务里最容易出问题的地方：同一个字段如果被不同服务用不同连接时区读写，TIMESTAMP 展示值可能变化。

三、范围和存储大小也不同

不同 MySQL 版本细节可能略有差异，但常见认知是：DATETIME 范围更大，TIMESTAMP 范围较小。

类型	典型语义	范围特点	时区转换
`DATETIME`	日期时间字面值	范围更大	通常不转换
`TIMESTAMP`	绝对时间点	范围较小	会转换

如果要保存生日 1990-01-01 00:00:00，DATETIME 更自然。若保存系统创建时间，TIMESTAMP 配合统一时区也很常见。

面试回答不必死背每个版本的字节细节，重点是把业务语义和时区行为讲清楚。

四、默认值和自动更新时间

TIMESTAMP 经常用于：

created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

DATETIME 在现代 MySQL 中也可以配合默认当前时间使用：

created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

所以不要把“只有 TIMESTAMP 支持自动更新时间”当作绝对结论。实际要看 MySQL 版本和字段定义。

工程上常见做法是统一时间策略：要么数据库统一 UTC，要么服务层统一转换，不要让多个层各自处理时区。

五、业务场景怎么选

选择时间类型先看业务含义。

场景	推荐倾向	原因
创建时间、更新时间	`TIMESTAMP` 或统一 UTC `DATETIME`	表示系统事件点
生日	`DATE` 或 `DATETIME`	不应随时区变化
会议本地开始时间	`DATETIME` + 时区字段	需要保留当地日历语义
日志时间	`TIMESTAMP`	表示绝对发生时刻

如果业务要表达“纽约当地 9 点开会”，只存一个 TIMESTAMP 可能不足，还需要保存时区或地区信息，否则夏令时等问题会让还原变复杂。

六、常见排查问题

时间字段问题常表现为“数据库里时间差 8 小时”“本地和线上不一致”“跨地区展示错位”。

排查路径：

SELECT @@global.time_zone, @@session.time_zone;
SELECT NOW(), UTC_TIMESTAMP();

再检查应用连接参数、ORM 时区配置、服务器系统时区和字段类型。很多事故不是 MySQL 时间类型本身错，而是数据库、应用、序列化层时区策略不一致。

一个简单原则是：存储层统一，展示层转换。比如存 UTC，用户界面按用户时区展示。

七、常见误区与追问

误区：DATETIME 和 TIMESTAMP 只是名字不同。 它们在时区语义、范围和自动转换上有明显差异。
误区：所有时间字段都应该用 TIMESTAMP。 生日、预约本地时间等场景不一定适合自动时区转换。
误区：时间差 8 小时一定是数据库 bug。 常见原因是连接时区、系统时区、应用序列化配置不一致。
误区：TIMESTAMP 的展示值永远不变。 不同会话时区读取可能展示不同本地时间。
追问：创建时间用哪个？ 可以用 TIMESTAMP，也可以用 UTC DATETIME，关键是团队统一策略。
追问：只保存日期用什么？ 用 DATE 更合适，不需要硬塞到 DATETIME。

八、加强记忆

时间类型题用“时区、范围、语义、场景”来答。DATETIME 保存日历时间，TIMESTAMP 表示时间点并受时区影响；跨时区系统最怕策略混乱，字段类型、连接时区、应用展示必须统一。

简化版

详细版