MySQL的time_zone_info表为空是因为安装后未执行mysql_tzinfo_to_sql导入系统时区数据；该表需手动初始化才能使CONVERT_TZ()、TIMESTAMP转换和SET time_zone正常工作。
MySQL 的 time_zone_info 表不是“加载”出来的，而是靠初始化时区表（mysql_tzinfo_to_sql）+ 手动导入系统时区数据生成的；不执行这一步，CONVERT_TZ()、TIMESTAMP 自动转换、SET time_zone 都会失效或退化为 UTC。
为什么 time_zone_info 表是空的？
MySQL 安装后默认不导入时区数据 —— 它只建了表结构，没填数据。哪怕你改了 my.cnf 里的 default-time-zone，也只影响会话/全局时区变量，不影响底层转换能力。
常见错误现象：SELECT CONVERT_TZ(NOW(), '+00:00', 'Asia/Shanghai') 返回 NULL；SELECT * FROM mysql.time_zone_name 查不到任何记录；SET time_zone = 'Asia/Shanghai' 看似成功，但 TIMESTAMP 列存值仍按 UTC 解析。
- 根本原因：缺少
mysql.time_zone*六张表的数据（time_zone、time_zone_name、time_zone_transition等） - 这些表依赖操作系统时区文件（如
/usr/share/zoneinfo/下的二进制文件），不是 MySQL 自带的 - Windows 用户尤其容易卡住：默认没装
zoneinfo数据，也没mysql_tzinfo_to_sql工具
用 mysql_tzinfo_to_sql 导入系统时区数据
这是唯一标准方式。它读取系统 /usr/share/zoneinfo/（Linux/macOS）或你手动提供的时区包，转成 SQL 插入语句。
实操步骤：
- 确认系统有 zoneinfo：运行
ls /usr/share/zoneinfo/Asia/Shanghai，能输出文件才可继续 - 生成 SQL：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql - 如果提示命令未找到：Ubuntu/Debian 需装
mysql-client包；CentOS/RHEL 装mysql-community-client - 导入后验证：
SELECT COUNT(*) FROM mysql.time_zone_name WHERE Name LIKE 'Asia%';应返回几十条
注意：mysql_tzinfo_to_sql 不支持 Windows 原生路径，WSL 或 Docker 是更稳妥的选择。
SET time_zone 和 default-time-zone 的真实作用范围
这两个配置只决定「时间字面量如何解释」和「TIMESTAMP 如何存储/显示」，不解决跨时区转换能力缺失的问题。
-
default-time-zone = '+08:00'（my.cnf）：让新连接默认使用该偏移，但无法用'Asia/Shanghai'这类命名时区（除非已导入time_zone_info） -
SET time_zone = 'Asia/Shanghai'：仅当mysql.time_zone*表有数据时才生效；否则自动 fallback 到+00:00，且不报错 -
TIMESTAMP列始终按服务器时区存 UTC 值，读取时转为当前会话时区 —— 这个“转换”依赖time_zone_info表，不是简单加减偏移
性能影响很小，但若表为空还频繁调用 CONVERT_TZ()，每次都会返回 NULL，容易引发业务逻辑误判。
Docker 或云数据库怎么处理？
容器环境常被忽略：基础镜像（如 mysql:8.0）不含 zoneinfo 文件，mysql_tzinfo_to_sql 会失败或导入空数据。
- Dockerfile 中必须显式复制或安装时区数据：
RUN apt-get update && apt-get install -y tzdata（Debian）或yum install -y tzdata（CentOS） - 阿里云 RDS、腾讯云 CVM 上的 MySQL：默认不开启时区表，需提工单或在控制台执行初始化（部分版本支持一键导入）
- 云厂商托管实例若禁止写
mysql库，则CONVERT_TZ()无法使用，只能靠应用层处理时区
最容易被忽略的是：即使你用 docker run -e TZ=Asia/Shanghai 启动容器，MySQL 内部时区表仍是空的 —— 容器时区 ≠ MySQL 时区表。
