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:00SELECT 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 服务端时区，而不同步修改应用层逻辑和建表策略，问题只会以另一种形式反复出现。
