目录
- 一、MySQL 设置为 UTC 后，JDBC URL 还需要特殊处理吗？
- 1. 推荐 JDBC URL 配置（MySQL 8.x）
- 2. 为什么
serverTimezone=UTC仍然必须？
- 二、Java 进程需要做哪些统一时区配置？
- 1. JVM 层：强烈建议统一 UTC
- 2. 为什么 JVM 时区必须统一？
- 三、时间戳 / DATETIME / TIMESTAMP，到底用哪个？
- 1. MySQL 的三种时间类型对比
- 2. 推荐方案（企业级主流）
- ✅ 方案 A：DATETIME + 全链路 UTC（最推荐）
- ⚠️ 方案 B：BIGINT 时间戳（可接受）
- ❌ 不推荐：TIMESTAMP
- 四、Java 实体层的正确写法（非常关键）
- 1. 推荐映射
- 2. 示例（MyBatis / JPA 通用）
- 五、前端 & 业务层的时区策略（很多系统忽略）
- 示例：
- 六、最终推荐的“全球化时间规范”（可写入架构文档）
- 七、一句话总结
- 数据库时间统一 UTC
- JVM 强制 UTC
- JDBC URL 显式
serverTimezone=UTC - DB 使用
DATETIME(3) - Java 使用
LocalDateTime - 前端按用户时区渲染
- 禁止使用 TIMESTAMP
一、MySQL 设置为 UTC 后，JDBC URL 还需要特殊处理吗？
结论：需要，而且是强烈建议显式配置。
即便你已经把 MySQL Server 时区设置为 UTC，JDBC URL 仍然必须显式声明时区与时间行为，否则在跨区域部署时非常容易踩坑。
1. 推荐 JDBC URL 配置（MySQL 8.x）
jdbc:mysql://host:3306/db
?useUnicode=true
&characterEncoding=utf8
&useSSL=false
&serverTimezone=UTC
2. 为什么 serverTimezone=UTC 仍然必须？
原因在于 MySQL JDBC Driver 的时间解析机制：
-
JDBC 驱动在 反序列化 DATETIME / TIMESTAMP 时
-
并不总是信任 MySQL server 的 global time_zone
-
如果不显式指定：
- 可能使用 JVM 默认时区
- 或触发
The server time zone value ... is unrecognized警告 - 不同节点（东南亚 / 欧洲）行为可能不一致
结论一句话：
MySQL 是 UTC ≠ JDBC 一定按 UTC 解析
二、Java 进程需要做哪些统一时区配置？
1. JVM 层：强烈建议统一 UTC
-Duser.timezone=UTC
或者在容器 / 启动脚本中：
export TZ=UTC
2. 为什么 JVM 时区必须统一？
如果 JVM 使用本地时区（如 Asia/Singapore）：
new Date()LocalDateTime.now()- ORM（Hibernate / MyBatis）默认行为
都会隐式依赖 JVM 时区
即使 DB 是 UTC，JVM 不是 UTC，照样会发生时间漂移
三、时间戳 / DATETIME / TIMESTAMP，到底用哪个？
这是全球化系统的关键设计点。
1. MySQL 的三种时间类型对比
| 类型 | 是否带时区 | 存储含义 | 风险 |
|---|---|---|---|
TIMESTAMP |
❌ | UTC → 会随 session time_zone 转换 | 多区域易混乱 |
DATETIME |
❌ | 纯字面值 | 推荐 |
BIGINT（epoch） |
隐式 UTC | 时间戳 | 可用，但可读性差 |
2. 推荐方案（企业级主流）
✅ 方案 A：DATETIME + 全链路 UTC（最推荐）
created_at DATETIME(3) NOT NULL
updated_at DATETIME(3) NOT NULL
约束：
- DB：UTC
- JVM：UTC
- JDBC：UTC
- 前端展示：按用户时区转换
优点：
- 可读性好
- 无 MySQL session time_zone 副作用
- 和 Java
LocalDateTime完美匹配 - 多区域部署稳定
⚠️ 方案 B：BIGINT 时间戳（可接受）
created_at BIGINT NOT NULL -- milliseconds since epoch
适用场景：
- 高并发写入
- 对时间排序 / 比较极端敏感
- 事件流、日志、埋点系统
缺点：
- SQL 可读性差
- BI / 报表友好度低
❌ 不推荐：TIMESTAMP
TIMESTAMP 最大的问题不是 UTC，而是“自动时区转换”
在以下场景极易出错：
- 不同 MySQL Session time_zone
- CDC / binlog
- 数据迁移
- 多语言客户端
四、Java 实体层的正确写法（非常关键）
1. 推荐映射
| DB 类型 | Java 类型 |
|---|---|
DATETIME |
LocalDateTime |
BIGINT |
Instant / long |
不要混用 Date / Calendar（历史包袱）
2. 示例（MyBatis / JPA 通用）
@Column(name = "created_at")
private LocalDateTime createdAt;
生成时间：
LocalDateTime now = LocalDateTime.now(ZoneOffset.UTC);
五、前端 & 业务层的时区策略（很多系统忽略）
核心原则：
存储 / 计算统一 UTC，展示按用户时区
示例：
-
数据库存：
2025-03-10 12:00:00（UTC） -
用户在：
- 新加坡 → +8 →
20:00 - 巴西 → -3 →
09:00
- 新加坡 → +8 →
六、最终推荐的“全球化时间规范”（可写入架构文档）
强烈建议你在 B 端全球销售系统中明确以下约束：
- 数据库时间统一 UTC
- JVM 强制 UTC
- JDBC URL 显式
serverTimezone=UTC - DB 使用
DATETIME(3) - Java 使用
LocalDateTime - 前端按用户时区渲染
- 禁止使用 TIMESTAMP
七、一句话总结
MySQL 设为 UTC 只是第一步，JDBC 和 JVM 不统一，时间照样会出问题。
企业级全球系统：DATETIME + 全链路 UTC，是目前最稳妥、最低心智负担的方案。
如果你愿意，我可以直接帮你：
- 输出一份《全球化时间规范（Architecture Decision Record）》
- 或评审你现有表结构 / ORM 映射是否有风险