MySQL升级后时区表缺失是因mysql_upgrade不处理时区表，需用对应版本的mysql_tzinfo_to_sql工具手动导入；补全后还需确保my.cnf、JDBC连接串及客户端配置统一使用'Asia/Shanghai'等命名时区，避免偏移量覆盖。
MySQL升级后时区表缺失，不是“漏装”，而是升级过程没触发时区表初始化——mysql.time_zone* 系统表不会随 mysql_upgrade 自动重建，尤其在跨大版本（如 5.7 → 8.0）或重装式升级后，必须手动补全。
为什么升级后时区表会空？
MySQL 的时区表（mysql.time_zone、mysql.time_zone_name 等）属于系统库结构，但不参与 binlog 同步，也不被 mysql_upgrade 默认处理。官方明确说明：该命令只更新权限表（user、db）、数据字典兼容性字段等，不加载时区数据。
- 从 5.7 升级到 8.0 且未保留旧数据目录 → 时区表彻底丢失
- 用
mysqld --initialize新建实例 → 时区表为空（除非显式加载） - 容器部署中挂载了空/精简版
/var/lib/mysql→ 表存在但无数据
如何安全补全时区表？
必须用对应 MySQL 版本的 mysql_tzinfo_to_sql 工具，配合操作系统时区数据库执行导入。Windows 用户请跳过此步，直接用偏移量（如 '+08:00'）避免依赖。
- 确认工具版本匹配：
mysql_tzinfo_to_sql --version输出应与mysqld --version一致；混用 5.7 工具连 8.0 实例会报Unknown table 'column_statistics' - Linux 下执行（需 root 权限）：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql - 验证是否成功：
SELECT COUNT(*) FROM mysql.time_zone_name WHERE Name = 'Asia/Shanghai';返回 1 才算到位 - 若提示
Access denied，检查账号是否有INSERT权限（不只是SELECT）
补完后仍无法用 'Asia/Shanghai'？检查三处硬编码
时区表有了，不代表连接就能用命名时区——应用层、服务层、客户端三处配置必须对齐，任一环节写死偏移量都会绕过命名时区解析。
-
my.cnf中default-time-zone设为'Asia/Shanghai'（不能是SYSTEM或'+08:00'） - JDBC 连接串中
serverTimezone必须显式设为Asia/Shanghai（URL 编码为serverTimezone=GMT%2B8是错的，那是偏移量） - PHP/Python 等客户端首次连接后，别再执行
SET time_zone = '+08:00'——这会覆盖会话级命名时区
最易被忽略的是：即使表已加载、配置全对，如果应用连接时用了 serverTimezone=UTC，MySQL 仍会把 NOW() 解释成 UTC 时间再转本地，结果比预期慢 8 小时。命名时区生效的前提，是整条链路都放弃偏移量思维。
