MySQL服务端时区设为SYSTEM且系统为UTC时，NOW()返回UTC时间，比北京时间少8小时；需修改配置文件default-time-zone='+08:00'并重启服务，JDBC连接须加serverTimezone=GMT%2B8&useTimezone=true，DATETIME不自动转换时区而TIMESTAMP会。
MySQL 服务端时区设成了 SYSTEM，但系统本身是 UTC
最常见的情况：MySQL 配置里写了 default-time-zone = SYSTEM（或压根没配），而操作系统时区其实是 UTC —— 比如 Docker 官方镜像、Alpine 系统、部分云服务器初始化环境，默认就是 UTC。这时 MySQL 会“老实”地跟着系统走，NOW() 返回的就是 UTC 时间，比东八区的北京时间少 8 小时。
验证方法：SELECT @@global.time_zone, @@session.time_zone; 如果返回 SYSTEM，再执行 SELECT NOW(); 对比系统命令 date 输出，差 8 小时基本坐实。
- 别只靠
SET GLOBAL time_zone = '+08:00'临时改 —— 重启后失效 - 必须改配置文件（如
/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]下加default-time-zone = '+08:00' - 改完一定要
systemctl restart mysql，不是 reload
JDBC 连接没声明 serverTimezone，驱动按 JVM 时区解析 TIMESTAMP
即使 MySQL 服务端已设对，Java 应用存 TIMESTAMP 字段仍可能差 8 小时 —— 因为 MySQL JDBC 驱动默认把传入的时间按 JVM 本地时区解释，再转成服务端时区存；如果 JVM 时区是 UTC（常见于容器内未显式设置），而服务端是 +08:00，就会多转一次。
典型表现：Java 里 new Date() 打印是 14:00 CST，入库后查出来变成 06:00。
- 连接串必须加上
?serverTimezone=GMT%2B8&useTimezone=true -
useTimezone=true是开关，不加它，serverTimezone参数会被忽略 - 避免用
Asia/Shanghai—— 部分精简镜像缺 tzdata，连接直接失败
DATETIME 和 TIMESTAMP 对时区的处理完全不一样
很多人以为“把 MySQL 时区设对就万事大吉”，结果发现老数据还是不对 —— 因为 DATETIME 类型根本不理会时区：它存什么，读出来就是什么；而 TIMESTAMP 会在写入和读取时自动按会话时区做转换。
这意味着：default-time-zone 改了，只影响新插入的 TIMESTAMP 值；已存的 DATETIME 不会变，也不会“自动修正”。
- 查老数据时差 8 小时？大概率字段类型是
DATETIME，且当初存的就是 UTC 时间 - 想统一行为，新表优先用
TIMESTAMP，或干脆全用UTC_TIMESTAMP()存 + 应用层转换 - 别指望 ALTER COLUMN 能“修复”历史
DATETIME值 —— 它们就是字面值，没时区元信息
Docker 容器里 MySQL 的时间来自宿主机，但时区文件可能缺失
Docker 启动 MySQL 容器时，/etc/localtime 和 /usr/share/zoneinfo/ 这两样东西如果不挂载或没装，容器内连 Asia/Shanghai 都识别不了，default-time-zone = 'Asia/Shanghai' 直接启动失败，退回到 SYSTEM（即 UTC）。
现象：容器里 date 显示正确，但 MySQL 里 NOW() 仍是 UTC —— 说明系统时间和 MySQL 时区没对齐。
- 启动时加
-e TZ=Asia/Shanghai只影响 shell 层，不影响 MySQL 服务进程 - 稳妥做法：挂载宿主机的
/usr/share/zoneinfo/Asia/Shanghai到容器内相同路径，再配default-time-zone = '+08:00' - 进容器手动试：
ls -l /etc/localtime看是否指向 zoneinfo，mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql确保时区表加载
真正麻烦的不是改哪一行配置，而是链路上每个环节都得对齐：系统时区、MySQL 服务端、JDBC 连接参数、字段类型语义、甚至容器镜像的基础环境。漏掉任意一环，8 小时就悄悄回来。
