MySQL配置文件中default-time-zone必须写在[mysqld]段落下，不能放在[client]或[mysql]中；值须为+HH:MM格式（如'+08:00'），写错位置或格式将导致重启后@@global.time_zone仍为SYSTEM。
MySQL配置文件里default-time-zone写在哪一行
必须写在[mysqld]段落下，不能放在[client]或[mysql]里。MySQL启动时只读取[mysqld]节下的default-time-zone，其他位置写了也无效。
常见错误是直接加在配置文件顶部、或者误塞进客户端配置块，结果重启后SELECT @@global.time_zone;还是SYSTEM，时区根本没变。
- 正确位置示例：
[mysqld] default-time-zone = '+08:00'
- 不支持写成
default-time-zone = 'Asia/Shanghai'（除非系统已安装对应时区表且MySQL编译时启用了时区支持） - 值必须是
+HH:MM或-HH:MM格式，不能省略冒号，也不能用+8或UTC+8
改完配置后MySQL不生效的三个典型原因
改了my.cnf不等于MySQL就用了新时区——多数问题出在加载路径、权限或服务控制上。
- MySQL没读你改的那个文件：用
mysqld --verbose --help | grep "Default options"确认它实际加载的配置路径，常见有/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf，Docker容器里还可能是/etc/mysql/conf.d/xxx.cnf - 配置文件权限不对：MySQL进程用户（如
mysql）必须有读取权限，chmod 644 /etc/my.cnf比777更安全 - 只执行
service mysql reload不够：这个命令通常只重载部分参数，default-time-zone属于启动期只读变量，必须service mysql restart或systemctl restart mysqld
验证default-time-zone是否真正生效
别只信配置文件内容，要查运行时状态。两个关键检查点：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 全局变量：
SELECT @@global.time_zone;—— 必须返回你设的+08:00，不是SYSTEM - 会话变量：
SELECT @@session.time_zone;—— 默认应与全局一致，但如果客户端连接时指定了time_zone参数，会覆盖它 - 顺便验证时间函数：
SELECT NOW(), UTC_TIMESTAMP();，两者差值应稳定为8小时（设为+08:00时）
注意：default-time-zone只影响新连接的默认会话时区，对已存在的连接无效；如果应用层显式执行了SET time_zone = '...'，也会覆盖该设置。
docker run或Kubernetes中设置default-time-zone的特殊处理
容器环境没有传统my.cnf可直接编辑，得靠挂载或启动参数注入。
- Docker命令行方式：
docker run -e MYSQL_TIME_ZONE='+08:00' ...—— 这个环境变量仅对官方镜像有效，且底层仍是生成/etc/mysql/conf.d/docker.cnf - 更可靠的是挂载自定义配置：
docker run -v $(pwd)/my.cnf:/etc/mysql/conf.d/timezone.cnf ...，文件内容必须含[mysqld]头和default-time-zone行 - K8s ConfigMap方式：确保ConfigMap挂载后文件权限为
644，且Pod内路径在MySQL搜索列表中（比如/etc/mysql/conf.d/）
容易被忽略的是：MySQL容器首次启动时若数据目录为空，会初始化数据库并可能忽略后续挂载的配置——务必在初始化完成后才挂载时区配置，或使用initdb脚本预置。
