必须显式设为+08:00而非Asia/Shanghai，因后者依赖未加载的mysql.time_zone_name表，易在容器、升级或Windows下失效，且存在历史映射歧义；+08:00硬编码偏移，稳定可靠。
必须显式设为 +08:00，不能用 Asia/Shanghai；否则 TIMESTAMP 字段会在主从同步、容器重建或系统升级后悄无声息地错乱。
为什么 Asia/Shanghai 在 MySQL 里不安全
MySQL 对命名时区的支持依赖 mysql.time_zone_name 表，而该表默认未加载——多数 Alpine、BusyBox 或精简版 Docker 镜像根本没装 tzdata，执行 SET time_zone = 'Asia/Shanghai' 直接报错：ERROR 1298 (HY000): Unknown or incorrect time zone。即使手动导入过，系统升级后时区规则可能变更，导致历史 TIMESTAMP 解析结果漂移（比如某条记录原解析为 2025-03-15 14:00:00，升级后变成 2025-03-15 15:00:00）。
+08:00 是硬编码偏移，启动即生效，不查表、不依赖系统、不随外部更新变动，所有环境（包括无 /usr/share/zoneinfo 的容器）都可稳定运行。
- 验证是否已加载命名时区：
SELECT COUNT(*) FROM mysql.time_zone_name WHERE Name = 'Asia/Shanghai';—— 返回0就别碰它 -
Asia/Shanghai在旧系统中曾映射过+09:00（伪夏令时残留），+08:00绝对无歧义 - Windows 环境下
Asia/Shanghai支持更不稳定，直接用+08:00省心
default-time-zone = '+08:00' 必须写进 my.cnf 并重启
只执行 SET GLOBAL time_zone = '+08:00' 是无效兜底：它需要 SYSTEM_VARIABLES_ADMIN 权限（应用账号通常没有），且 MySQL 重启后立即丢失；已有连接的 @@session.time_zone 也不会变，照样读错数据。
正确做法是编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，在 [mysqld] 段添加：
default-time-zone = '+08:00'
然后强制重启：systemctl restart mysql（Docker 需重建容器）。验证是否生效：
-
SELECT @@global.time_zone, @@session.time_zone;—— 两者都应返回+08:00，不是SYSTEM -
SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP);—— 结果必须是08:00:00 - 别信
@@system_time_zone，它只是启动时读的一次快照，和业务无关
JDBC 连接串漏配 serverTimezone 是线上最常见坑
就算 MySQL 服务端设成 +08:00，JDBC 8.0+ 驱动默认仍按 JVM 本地时区解析时间：Java 传入 new Timestamp(1752364800000L)（对应北京时间 2025-07-15 00:00:00），驱动会先转成 UTC 时间再发给 MySQL，MySQL 又按自己的 time_zone 转一次——双重转换，差 8 小时就出来了。
连接串必须带：
?serverTimezone=Asia/Shanghai&useTimezone=true
注意点：
-
GMT%2B8多数驱动不识别，必须用 IANA 名称（Asia/Shanghai） -
spring.jackson.time-zone对数据库层完全无效，别指望它 - Docker 部署时，确保 JVM 启动参数也设了
-Duser.timezone=Asia/Shanghai，避免驱动 fallback 到UTC
TIMESTAMP 和 DATETIME 的行为差异不能靠“感觉”混用
TIMESTAMP 存的是 UTC 秒数，读取时按当前会话 time_zone 自动换算；DATETIME 是纯字面值，time_zone 设置对它完全没影响。线上出问题，八成是字段类型选错了。
- 日志时间、订单创建时间等需跨时区统一比对的字段：用
TIMESTAMP+ 固定+08:00（服务端和连接层双锁定） - 身份证有效期、合同截止日等“绝对日期”：用
DATETIME，并在应用层确保输入已是东八区时间（如'2030-12-31 23:59:59'） - 如果历史数据用
DATETIME存了 UTC 时间，但一直当北京时间用，改time_zone不会修复——只能用DATE_ADD(created_at, INTERVAL 8 HOUR)批量修正 - 混合
ORDER BYTIMESTAMP和DATETIME列时，MySQL 可能隐式转换导致结果错乱
真正难的不是配置，是确认每一条时间字段背后的真实语义：它代表的是一个全球统一的时间点，还是某个时区下的固定时刻？这个判断一旦出错，后续所有时区设置都是徒劳。
