为何在MySQL 8.0中必须设定默认时区才能防止时间偏差

MySQL 8.0默认使用SYSTEM时区，易因系统时区非+08:00导致8小时偏差；必须通过my.cnf配置default-time-zone='+08:00'并重启服务永久生效，配合验证SELECT @@global.time_zone及TIMEDIFF(NOW(), UTC_TIMESTAMP)确保为08:00:00。

MySQL 8.0 默认不设固定时区，它默认用 SYSTEM（即系统时区），而系统时区极可能不是 +08:00 —— 这就是 8 小时偏差的根源。

为什么 default-time-zone 不配就必然出问题

MySQL 启动时只读一次系统时区，之后就缓存为 SYSTEM。但很多环境根本不是东八区：Docker 官方镜像默认 UTC、Alpine 镜像没装 tzdata、云服务器初始化常设为 UTC 或 CST（歧义时区）、Windows 主机时区被误改……这些都会让 @@global.time_zone 返回 SYSTEM，而实际偏移却是 +00:00 或乱码值。

验证方法必须两步走：

• SELECT @@global.time_zone, @@session.time_zone; —— 看返回是不是 SYSTEM 或 +00:00
• SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP); —— 理想结果是 08:00:00；若为 00:00:00，说明 NOW() 实际输出的是 UTC 时间

default-time-zone = '+08:00' 和 'Asia/Shanghai' 的实际区别

写 default-time-zone = '+08:00' 是最稳妥的选择，尤其在线上或容器环境：

• '+08:00' 是硬编码偏移，MySQL 启动即认，不依赖系统 tzdata，Alpine、BusyBox 镜像也能跑
• 'Asia/Shanghai' 需要 MySQL 时区表已加载，否则启动直接报错：ERROR 1298 (HY000): Unknown or incorrect time zone
• 若真要用命名时区，必须提前执行：mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql，再查 SELECT COUNT(*) FROM mysql.time_zone_name; 确保 > 0

SET GLOBAL time_zone = '+08:00' 为什么不能替代配置文件

这条命令只是临时生效，有三个硬限制：

• 只影响后续新建连接，当前会话的 @@session.time_zone 不变
• 需要 SYSTEM_VARIABLES_ADMIN 权限，普通应用账号通常没有，强行赋权反而引入安全风险
• MySQL 重启后立即失效 —— 而生产环境重启太常见（内核升级、配置热更失败回滚、宿主机重启等）

DATETIME 和 TIMESTAMP 字段让时区问题更隐蔽

哪怕你把服务端时区全设对了，字段类型选错照样出事：

• TIMESTAMP 存的是 UTC，读取时按当前会话时区自动转换 —— 同一条记录，在 +08:00 会话里看到的是北京时间，在 +00:00 会话里看到的就是早 8 小时的 UTC 值
• DATETIME 完全不转换，原样存原样取 —— 所以如果历史数据是用 DATETIME 存的 UTC 时间，改时区根本救不回来，只能用 DATE_ADD(created_at, INTERVAL 8 HOUR) 批量修正
• 新表设计优先用 DATETIME，除非你明确需要跨时区自动归一化（比如全球日志时间统一转本地显示）

真正容易被忽略的点是：**时区配置只是前提，客户端连接串、驱动行为、字段类型三者必须对齐，缺一不可。** 单改 MySQL 服务端，不碰应用层和建表逻辑，问题只会换个方式出现。