为什么MySQL 8.0必须配置默认时区避免时间偏差？

MySQL 8.0 在时区处理上有一个长期存在的问题一直未解决——默认情况下，它不设定固定时区，而是直接使用系统时区。而系统时区往往不是 +08:00，这就是 8 小时偏差的根源。

为什么默认不配置就一定会出问题

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 时间

'+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 为什么不能替代配置文件

这条命令仅临时生效，存在三个硬性限制：

• 只影响后续新建连接，当前会话的 @@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 服务端，而不处理应用层和建表逻辑，问题只会以另一种形式出现。