历史数据必须用 DATETIME，因为 TIMESTAMP 基于 32 位 Unix 时间戳，最大仅支持到 '2038-01-19'，插入超限值会静默截断；DATETIME 不涉及时区转换，值恒定，且自 MySQL 5.6.5 起支持多字段自动更新。
直接结论：历史数据必须用 DATETIME，因为 TIMESTAMP 无法可靠表示 2038 年之后的任何时间点，且时区转换会让“同一条记录在不同连接里显示不同时间”——这不是 bug，是设计行为。
为什么 TIMESTAMP 存不了历史数据？
它根本就不是为“历史”设计的：TIMESTAMP 底层存的是 Unix 时间戳（32 位有符号整数），最大值固定死在 '2038-01-19 03:14:07.999999'。你插入 '2050-01-01'，MySQL 不报错，而是静默截断为 '0000-00-00 00:00:00' 或 NULL（取决于 SQL mode 和 explicit_defaults_for_timestamp 设置）。
常见踩坑场景：
- 会员有效期设 30 年，2026 年创建 → 到期日为
'2056-06-02'，TIMESTAMP直接失效 - 古籍文献归档时间写
'1200-05-15'，TIMESTAMP拒绝插入或转成 0 值 - 合同签署日期填
'2100-12-31'，查出来是空，前端展示异常却无日志报警
DATETIME 怎么避免时区混乱？
DATETIME 不参与任何时区转换：插进去什么，查出来就是什么。它不关心服务器时区、会话时区、连接池配置，也不依赖 time_zone 系统变量。
这意味着：
- 运维半夜把服务器时区从
+08:00改成UTC，所有DATETIME字段值完全不变 - 同一个查询在新加坡、旧金山、柏林的连接里执行，返回的
created_at字符串一模一样 - 你不需要在应用层做“统一转 UTC 再存”的逻辑，也不用担心 ORM 自动注入了错误的时区上下文
代价是你得自己管好“这个时间到底属于哪个时区”——比如用户提交的 '2026-06-02 10:49:00' 是本地时间？还是已按东八区标准化过？这属于业务语义，不是数据库该替你决定的。
自动更新功能现在 DATETIME 也能用
老资料常说 “TIMESTAMP 支持 ON UPDATE CURRENT_TIMESTAMP，DATETIME 不行”，这早过时了。MySQL 5.6.5+ 起，DATETIME 已完全支持：
CREATE TABLE orders ( id BIGINT PRIMARY KEY, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
关键点：
- 你可以同时定义多个
DATETIME字段带默认值和自动更新，没有TIMESTAMP那种“一张表只能有一个默认CURRENT_TIMESTAMP”的硬限制 - 不需要为了“创建时间 + 更新时间”而混用类型，结构更干净，迁移更安全
- 如果用了
explicit_defaults_for_timestamp = ON（MySQL 8.0 默认），TIMESTAMP反而要求显式声明所有默认值，漏写就报错Field 'ts' doesn't have a default value
真正容易被忽略的是：哪怕你只存“创建时间”，只要系统预期寿命超过 12 年（即可能运行到 2038 年后），TIMESTAMP 就不是远虑，而是上线即埋雷。而 DATETIME 的 '9999-12-31' 范围，在绝大多数业务生命周期内，等价于“永不溢出”。
