必须在初始化前配置default-time-zone，否则TIMESTAMP字段默认按UTC解析，导致东八区应用时间偏移8小时；因初始化时MySQL依据当时全局时区决定TIMESTAMP基准行为，且后续修改不改变已有数据的时区语义。
必须在初始化前就配置好 default-time-zone，否则初始化后所有 TIMESTAMP 字段默认按 UTC 解析，应用读写时间会天然偏移 8 小时（在东八区场景下）。
为什么初始化阶段就要设时区？
MySQL 8.0 启动时只读一次系统时区并缓存为 SYSTEM，而初始化（mysqld --initialize）过程会生成初始数据目录、root 临时密码，并**依据当时的全局时区设置决定 TIMESTAMP 类型字段的基准行为**。一旦初始化完成，后续再改 time_zone 只影响新写入或新查询，对已存在的 TIMESTAMP 值不触发转换 —— 这些值早已按初始化时刻的时区逻辑存为 UTC。
常见错误现象：
- 本地开发环境用
SET GLOBAL time_zone = '+08:00'，但部署时忘了配my.cnf，结果初始化出来的mysql.time_zone_name表为空，TIMESTAMP全部按 UTC 存 - 应用插入
NOW()，Java 里查出来比预期早 8 小时，但DATETIME字段却正常 —— 正是因字段类型和初始化时区不匹配所致
my.cnf 中 default-time-zone 怎么填才稳妥？
优先写偏移量，别写时区名。尤其在容器、Alpine、Windows 等环境，Asia/Shanghai 极易因时区表未加载而启动失败，报错：ERROR 1298 (HY000): Unknown or incorrect time zone。
正确写法（任选其一，推荐第一种）：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
default-time-zone = '+08:00'—— 启动即生效，不依赖系统tzdata，兼容性最强 -
default-time-zone = 'Asia/Shanghai'—— 仅当确认已执行过mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql，且SELECT COUNT(*) FROM mysql.time_zone_name> 0
注意：default-time-zone 必须放在 [mysqld] 段下，且 MySQL 8.0 不支持在 [client] 或 [mysql] 段中设置它。
初始化后必须验证的两个关键点
初始化并启动服务后，光看 @@global.time_zone 不够，得交叉验证：
- 执行
SELECT @@global.time_zone, @@session.time_zone;—— 确认返回不是SYSTEM或NULL，而是你设的+08:00或Asia/Shanghai - 执行
SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP);—— 理想结果是08:00:00；若返回00:00:00，说明NOW()实际输出的是 UTC 时间，初始化时区根本没生效
如果第二条验证失败，不要尝试用 SET GLOBAL time_zone 临时补救：它不影响已初始化的数据语义，且重启即丢。必须停服务、改配置、删 data 目录（开发环境）、重新 mysqld --initialize。
最易被忽略的一点：哪怕你把配置文件、初始化、JDBC 连接串里的时区全设对了，只要表里混用了 DATETIME（存本地时间）和 TIMESTAMP（存 UTC），应用层不做统一解释，时间混乱依然会发生。字段类型选型本身，就是时区策略的第一道防线。
