MySQL时区配置不生效因未设default-time-zone或未导入时区表；SET GLOBAL仅临时生效，重启后失效；default-time-zone需在[mysqld]段写为+08:00等合法格式并重启服务；客户端需显式指定serverTimezone避免解析偏差。
MySQL服务器时区配置不生效，通常是因为只改了time_zone变量却没碰default-time-zone，或者用了Asia/Shanghai但没加载时区表——这两类操作根本不会持久，重启后就回退。
为什么SET GLOBAL time_zone = '+8:00'重启后失效？
这个命令只修改运行时的全局变量，不写入配置文件。MySQL启动时仍按my.cnf里的default-time-zone（或默认SYSTEM）初始化time_zone值，覆盖你之前设的值。
-
SET GLOBAL time_zone适合紧急临时调整，比如排查日志时间错乱 - 它不能替代配置文件设置，也不影响新建立的连接的初始会话时区（除非显式
SET time_zone） - 执行后必须验证：
SELECT @@global.time_zone, @@session.time_zone;，避免误以为已生效
default-time-zone = 'Asia/Shanghai'报错1298怎么办？
错误信息是The server time zone value 'Asia/Shanghai' is unrecognized，说明MySQL没加载时区数据表。MySQL默认只认偏移量（如+08:00）和SYSTEM/UTC，用时区名必须先导入系统时区数据。
- 先确认系统时区路径：
ls /usr/share/zoneinfo/Asia/Shanghai（常见路径，CentOS/RHEL系）或/usr/share/zoneinfo/ - 导入命令：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql - 导入后才能在
my.cnf里安全使用default-time-zone = 'Asia/Shanghai' - 如果只是要东八区，直接写
default-time-zone = '+08:00'更省事、无依赖
修改my.cnf后MySQL服务起不来？
常见原因是default-time-zone写错位置或格式非法。它必须放在[mysqld]段内，且值不能带空格、引号（即使文档示例有单引号，实际配置中引号会导致启动失败）。
- 正确写法：
default-time-zone=+08:00或default-time-zone=SYSTEM - 错误写法：
default-time-zone = '+08:00'（等号两边有空格 + 引号）、default-time-zone="Asia/Shanghai" - 改完配置必须重启服务：
systemctl restart mysqld（不是reload，因为这是启动参数级配置） - 启动失败时查日志：
journalctl -u mysqld -n 50 --no-pager，重点看unknown variable或invalid default-time-zone类提示
客户端连接后时间还是不对？
即使服务器时区设对了，JDBC、Python MySQL Connector等驱动默认可能按本地时区解析TIMESTAMP，导致查询结果时间偏差8小时。这不是MySQL服务器问题，而是连接层行为。
- JDBC需显式加参数：
?serverTimezone=Asia/Shanghai或?serverTimezone=GMT%2B8 - Python
pymysql：传参timezone='+08:00'；mysql-connector-python：用time_zone='+08:00' -
TIMESTAMP列自动转换为会话时区，DATETIME列不转换——选哪种类型取决于业务是否需要自动时区适配
真正容易被忽略的是：系统时区（system_time_zone）无法运行时修改，它由操作系统决定，且time_zone = SYSTEM时每次调用都触发系统库调用，高并发下可能成为瓶颈。所以生产环境别留着SYSTEM，哪怕只是写死+08:00也比它强。
