核心区别
| 特性 | DATETIME | TIMESTAMP |
|---|---|---|
| 存储空间 | 8 字节 | 4 字节 |
| 时间范围 | 1000-01-01 ~ 9999-12-31 | 1970-01-01 ~ 2038-01-19 |
| 时区处理 | 存储原始值，不转换 | 存储为 UTC，读取时按会话时区转换 |
| 默认值 | 可设固定值 | 支持 CURRENT_TIMESTAMP 自动更新 |
| 自动更新 | 需手动/触发器 | 支持 ON UPDATE CURRENT_TIMESTAMP |
选择建议
✅ 选择 DATETIME 当：
- 需要存储历史日期（如出生日期、历史事件）
- 时间范围可能超出 2038 年
- 需要固定不变的时间记录（如订单创建时间，不因时区改变）
- 应用层已统一处理时区，不需要数据库介入
CREATE TABLE events (
event_time DATETIME NOT NULL DEFAULT '2024-01-01 00:00:00',
birthday DATETIME NOT NULL -- 出生日期，固定不变
);
✅ 选择 TIMESTAMP 当：
- 需要自动记录创建/更新时间
- 应用面向全球用户，需要时区自适应
- 存储空间敏感（节省 50%）
- 时间范围在 1970-2038 之间
CREATE TABLE users (
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
关键注意事项
1. TIMESTAMP 的 2038 年问题
2038-01-19 后 32 位 TIMESTAMP 会溢出。MySQL 8.0+ 已支持 64 位，但旧系统需警惕。
2. 时区陷阱
-- 会话时区改变，TIMESTAMP 显示值会变 SET time_zone = '+8:00'; SELECT ts FROM table; -- 显示北京时间 SET time_zone = '+0:00'; SELECT ts FROM table; -- 显示 UTC 时间（数值变了！）
DATETIME 不受此影响，始终显示存储时的原始值。
3. 混合使用策略（推荐）
CREATE TABLE orders (
-- 面向用户的本地时间，固定不变
order_time DATETIME NOT NULL,
-- 内部审计/日志，带时区信息
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
总结
| 场景 | 推荐类型 |
|---|---|
| 出生日期、历史日期、未来远期日期 | DATETIME |
| 记录创建/修改时间、全球化应用 | TIMESTAMP |
| 两者都需要 | 混合使用 |
一句话原则：需要"人类看到的固定时间"用 DATETIME；需要"系统记录的瞬时时刻"用 TIMESTAMP。
