绝大多数业务场景该用 datetime；只有明确需要自动时区转换且时间限定在1970–2038年时才考虑 timestamp，因其依赖服务器和会话时区易导致时间错乱，而 datetime 无隐式转换、范围大、精度高、更安全可靠。
DATETIME 和 TIMESTAMP 看似都能存“年月日时分秒”，但选错一个，轻则时间显示错乱，重则2038年后数据失效、跨时区订单对不上、日志时间倒流。直接结论：绝大多数业务场景该用 DATETIME；只有明确需要自动时区转换 + 严格限定时间在1970–2038年内时，才考虑 TIMESTAMP。
为什么 TIMESTAMP 的“自动时区转换”反而容易出事？
很多人以为“自动转时区=更智能”，实际它依赖两个外部变量：MySQL 服务器的 time_zone 设置 + 当前连接的会话时区。一旦不一致，写入和读取就不是同一个时间点。
- INSERT 时用的是会话时区（比如 '+08:00'），MySQL 把
'2026-08-12 15:00:00'转成 UTC 存（'2026-08-12 07:00:00'） - SELECT 时如果会话时区被临时改成 '+00:00'，查出来就是
'2026-08-12 07:00:00'—— 用户看到的比实际晚了8小时 - 应用层没显式设
SET time_zone = '+08:00'，而数据库配置是 UTC，那所有写入都偏移8小时，且无法回溯修正
典型报错现象：SELECT 结果随 SHOW VARIABLES LIKE 'time_zone'; 变动而跳变，或不同客户端连同一行数据，显示时间不一致。
DATETIME 没有时区转换，为什么更安全？
DATETIME 就是“所见即所得”：你 INSERT '2026-08-12 15:00:00'，无论服务器在哪、会话时区怎么切，SELECT 出来永远是 '2026-08-12 15:00:00'。它不帮你做任何隐式转换，也就不会因配置漂移导致数据语义错乱。
- 适合记录“绝对时间点”：比如订单创建时间、合同签署时间、审计日志发生时间 —— 这些时间本身就有明确时区归属（通常是业务所在时区），不该被数据库偷偷改掉
- 支持微秒精度（
DATETIME(6)），和TIMESTAMP(6)一样能存'2026-08-12 15:00:00.123456' - 范围大（1000–9999年），完全避开
TIMESTAMP的 2038 年溢出风险 —— 金融合约、长期档案、历史数据都稳得住
TIMESTAMP 唯一不可替代的场景是什么？
只有当你需要 **数据库层自动维护“最后更新时间”且必须适配用户本地时区展示** 时，TIMESTAMP 的 ON UPDATE CURRENT_TIMESTAMP 才有真实价值。
- 例如：客服工单表的
updated_at字段，希望每个坐席看到的都是自己本地时间的“最后修改时刻”，而不是统一 UTC 时间 - 必须同时满足：业务时间全在 1970–2038 年间 + 应用层无法/不愿在写入时手动计算时区 + 接受服务器时区配置强耦合
- 注意：
TIMESTAMP的默认值CURRENT_TIMESTAMP在 MySQL 5.6.5+ 才支持DATETIME，所以老版本若要用默认值，只能选TIMESTAMP
性能和存储差异真值得为 TIMESTAMP 冒险吗？
节省 4 字节（TIMESTAMP 4B vs DATETIME 8B）在现代 SSD 和内存面前几乎可忽略；索引效率两者完全一致。别拿“省空间”当理由选 TIMESTAMP —— 它真正的代价是隐式时区逻辑带来的调试成本和线上事故概率。
- 如果你真卡存储，优先考虑压缩行格式（
ROW_FORMAT=COMPRESSED）或归档旧数据，而不是赌TIMESTAMP的 4 字节 - 想兼容多数据库？
BIGINT存 Unix 时间戳更通用，但牺牲可读性；DATETIME至少人类可直读，SQL 调试不抓瞎 - 现在是 2026 年，离 2038 年只剩 12 年 —— 新建系统用
TIMESTAMP就等于提前埋下数据迁移倒计时
真正容易被忽略的点：时区逻辑不在 SQL 层而在连接层。哪怕你选了 TIMESTAMP，如果应用没统一管理连接时区（比如用连接池但没设 time_zone 初始化参数），结果比用 DATETIME 还不可控。
