不建议无差别用TIMESTAMP替代DATETIME，因其时区转换不可控（读取时按会话时区自动转换导致同一数据展示不一致）且时间范围窄（仅1970–2038年，超限静默截断），而DATETIME无时区转换、支持1000–9999年，更稳妥可靠。
MySQL 中不建议无差别用 TIMESTAMP 替代 DATETIME，核心原因就两个：时区转换不可控、时间范围太窄——尤其在跨时区服务或长期存档场景下，TIMESTAMP 很容易悄悄出错。
时区转换会让同一行数据“变时间”
TIMESTAMP 存的是 UTC 时间，但读取时会按当前会话时区自动转换。这意味着：
- 插入时用
SET time_zone = '+08:00'，值'2026-04-18 10:00:00'存进数据库后实际是 UTC 的'2026-04-18 02:00:00' - 如果另一个连接设了
time_zone = '+09:00'再查，返回的却是'2026-04-18 11:00:00'——不是数据错了，是 MySQL 帮你“翻译”了 -
DATETIME完全不参与这个过程，插进去什么，查出来就是什么，时区切换不影响值本身
典型踩坑场景：运维半夜改服务器时区、应用连接池复用不同 time_zone 设置的连接、前端展示依赖服务端时区却没统一配置。
TIMESTAMP 的 2038 年限制不是远虑，而是近忧
TIMESTAMP 最大只能存到 '2038-01-19 03:14:07.999999'（Unix 时间戳溢出点），而今天已经是 2026-04-18：
- 业务表里存“合同到期日”“用户生日”“历史归档时间”，只要可能超过 2038 年，
TIMESTAMP就直接失效 - MySQL 不会报错，而是静默截断为
'0000-00-00 00:00:00'或最近合法值，查出来是空或错乱时间 -
DATETIME支持到'9999-12-31 23:59:59.999999'，对绝大多数业务是“永远够用”
哪怕你只存“创建时间”，如果系统要运行 15 年以上，就得提前考虑 2038 年问题——这不是理论风险，是确定性边界。
自动更新行为在多字段场景下不可靠
虽然 TIMESTAMP 支持 ON UPDATE CURRENT_TIMESTAMP，但有硬限制：
- MySQL 5.6.5+ 允许
DATETIME也用ON UPDATE CURRENT_TIMESTAMP，功能已拉平 - 一张表里只能有一个
TIMESTAMP字段设默认值为CURRENT_TIMESTAMP；第二个会报错Invalid default value for 'xxx' - 如果同时需要“创建时间”和“更新时间”两个自动时间字段，用两个
TIMESTAMP行不通，必须混用或全用DATETIME
更麻烦的是：一旦表结构里已有 TIMESTAMP 字段带默认值，后续加新 TIMESTAMP 字段时，哪怕不设默认值，也可能因隐式约束失败。
真正需要 TIMESTAMP 的场景其实很窄：纯日志表、短期监控数据、且明确接受 UTC 存储 + 时区转换逻辑。其他情况，优先选 DATETIME 更省心——它不耍花招，不改你的值，也不卡在 2038 年。最容易被忽略的一点是：TIMESTAMP 的“节省空间”优势（4 字节 vs DATETIME(0) 的 5 字节）在现代 SSD 和内存成本下几乎可以忽略，但它的隐式行为代价远高于那 1 字节。
