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 服务端，不碰应用层和建表逻辑，问题只会换个方式出现。
