1. 为什么会有这么多时间类型
早期 MySQL 只有 DATE、TIME、YEAR，随着互联网业务对毫秒级、全球多活、历史数据的需求，逐渐扩展到 DATETIME(fsp)、TIMESTAMP(fsp)。每种类型在存储空间、时区处理、范围、性能上各有取舍，选错类型往往导致"线上时区惨案"或"索引失效"。
2. 五大原生类型
| 类型 | 格式示例 | 范围 | 存储(字节) | 时区感知 | 备注 |
|---|---|---|---|---|---|
| DATE | 2025-08-09 | 1000-01-01 ~ 9999-12-31 | 3 | 否 | 只存日期 |
| TIME[(fsp)] | 14:35:07.123 | -838:59:59.000000 ~ 838:59:59.000000 | 3 + fsp/2 | 否 | 可存时长 |
| DATETIME[(fsp)] | 2025-08-09 14:35:07.123 | 1000-01-01 00:00:00.000000 ~ 9999-12-31 23:59:59.999999 | 5 + fsp/2 | 否 | 推荐存"绝对时间" |
| TIMESTAMP[(fsp)] | 2025-08-09 14:35:07.123 | 1970-01-01 00:00:01 UTC ~ 2038-01-19 03:14:07 UTC | 4 + fsp/2 | 是 | 存 epoch 秒 |
| YEAR | 2025 | 1901 ~ 2155 | 1 | 否 | 节省空间 |
fsp：fractional seconds precision（0-6），MySQL 8.0 默认 0。
3. 内部存储格式
• DATE：3 byte，小端序，第 1 字节存 (year-1000)*16+month，后两字节存 day。
• DATETIME(0)：5 byte，年月日时分秒各压缩成 bit。
• TIMESTAMP：4 byte 有符号 int，存 epoch 秒，fsp 额外占 1-3 byte。
• 存储层完全透明，无需关心，但理解后更容易解释"为什么 DATETIME 范围更大"。
4. 时区、夏令时与 2038 问题
TIMESTAMP 在写入/读取时，通过系统变量 time_zone 自动 UTC↔会话时区转换，因此同一行数据在不同客户端可能显示不同字符串。
DST（夏令时）切换当天可能出现"重复 02:00"或"跳过 02:00"，MySQL 以 UTC epoch 秒存储，可规避该问题。
2038 问题：有符号 32 位 epoch 秒上限 2038-01-19；8.0 已支持 64 位，且官方建议迁移到 DATETIME(6) 或 BIGINT 保存微秒 epoch。
5. 性能与索引：DATETIME vs TIMESTAMP
• 存储空间：TIMESTAMP(0) 4B < DATETIME(0) 5B；带 fsp 后差距缩小。
• 索引：二者在 BTREE 里都是按字节排序，性能无差异；但 TIMESTAMP 范围小，回表过滤更快。
• 分区表：TIMESTAMP 无法直接做 RANGE COLUMNS 分区（因为内部是 INT）；DATETIME 可直接按天分区。
6. 8.0 新特性
a) fsp 最大 6 位，默认 0；
b) information_schema.time_zone* 表支持夏令时历史更完整；
c) NOW() 结果在 binlog/复制中持久化，保证主从时间一致；
d) cast('2025-08-09 14:35:07.123456' as datetime(6)) 不再四舍五入；
e) ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE 支持在线扩大 fsp。
7. 实战场景 & 代码片段
场景 1：订单创建时间（全球用户）
sql
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3)
) ENGINE=InnoDB;理由：不涉及时区转换，可读性强，范围足够。
场景 2：用户最后登录时间（需要自动转换时区）
sql
CREATE TABLE user_login (
user_id BIGINT PRIMARY KEY,
last_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);客户端会话各自设置 SET time_zone = '+08:00'，即可自动显示本地时间。
场景 3：事件时长统计
sql
SELECT TIMESTAMPDIFF(MICROSECOND, start_time, end_time) AS duration_us
FROM events;8. 常见误区与避坑清单
- 把生日存成 TIMESTAMP → 范围不够，1970 以前会报错。
SELECT * FROM t WHERE DATE(create_time) = '2025-08-09'→ 无法使用索引；改成BETWEEN '2025-08-09 00:00:00' AND '2025-08-09 23:59:59'。- 以为 DATETIME(0) 和 DATETIME(3) 空间一样 → 实际 5 vs 6 byte，大量行会浪费存储。
- 用 VARCHAR(19) 存时间 → 排序/比较需要 CAST，性能差且易出格式错误。
- 8.0 之前把 TIMESTAMP 默认值设为 '0000-00-00 00:00:00' → 会报 "Invalid default value"。
9. 小结
• 日期类 → DATE
• 绝对时间 → DATETIME(fsp)
• 时区感知 → TIMESTAMP(fsp)
• 只存年份 → YEAR
• 存时长 → TIME(fsp)
MySQL 8.0 之后，64 位 TIMESTAMP 已在实验室分支测试，未来有望彻底解决 2038 问题；官方也在考虑原生支持 TIMESTAMP WITH TIME ZONE（类似 PostgreSQL），让我们拭目以待。