MySQL时区不一致导致NOW()与SYSDATE()结果偏差，根源在于服务端启动读系统时区而客户端自带时区；需统一配置global/session时区、JDBC显式指定serverTimezone、优先使用DATETIME类型并写死default-time-zone。
MySQL 服务端时区和客户端时区不一致，NOW() 和 SYSDATE() 返回时间对不上
这是最常被忽略的根源：MySQL 服务端启动时读取系统时区（比如 /etc/timezone 或 systemd-timedated），但客户端连接时可能带自己的时区（如 JDBC 默认用 JVM 时区，Python pymysql 默认用本地系统时区）。结果就是同一条 SELECT NOW()，在命令行、Navicat、Java 应用里跑出来的时间差好几小时。
- 查服务端当前时区：
SELECT @@global.time_zone, @@session.time_zone; - 查系统实际时区：
SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP);（返回+08:00表示东八区） - 强制会话使用统一时区（临时）：
SET time_zone = '+08:00';或SET time_zone = 'Asia/Shanghai'; - 注意：
@@global.time_zone改了只影响新连接；老连接仍沿用建连时的 session 时区
JDBC 连接串没指定 serverTimezone，Java 应用写入时间全偏移
JDBC 驱动（尤其是 8.0+）默认不信任服务端时区声明，必须显式告诉它“服务器在哪一时区”，否则会把 java.util.Date 按客户端本地时区解释后转成 UTC 再发给 MySQL——而 MySQL 若设的是 SYSTEM，就又按系统时区解一次，双重转换直接错乱。
- 正确连接串示例：
jdbc:mysql://localhost:3306/test?serverTimezone=Asia/Shanghai&useTimezone=true - 错误写法：
serverTimezone=GMT%2B8（部分驱动不识别 GMT 偏移写法，优先用 IANA 时区名） - Spring Boot 用户注意：
spring.datasource.url里必须包含该参数，spring.jackson.time-zone管不到数据库层 - 如果 MySQL 服务端已设为
SYSTEM，且系统时区是Asia/Shanghai，那 JDBC 的serverTimezone必须严格匹配，不能写CST（歧义太大）
TIMESTAMP 列自动转换 vs DATETIME 不转换，字段类型选错放大时区问题
TIMESTAMP 存的是 UTC 时间戳，读写时会根据当前 session 时区自动转换；DATETIME 存的是字面值，不转换。很多人以为“存 TIMESTAMP 就能自动适配时区”，结果发现 Java 写入 2024-05-01 10:00:00，MySQL 里变成 2024-05-01 02:00:00——其实是 JDBC 把本地时间当成本地时区，转成 UTC 后存进 TIMESTAMP，再用另一个时区读出来，看起来像“错位”。
- 线上系统强烈建议统一用
DATETIME，业务逻辑自己控制时区含义（比如全部按 UTC 存，或全部按Asia/Shanghai存） - 如果坚持用
TIMESTAMP，必须确保所有客户端连接都设相同time_zone，且服务端global.time_zone不设为SYSTEM（避免系统重装/迁移后漂移） -
DEFAULT CURRENT_TIMESTAMP对TIMESTAMP是按 session 时区算的；对DATETIME是按服务端时区（@@global.time_zone）算的
MySQL 启动配置文件里 default-time-zone 写成了 SYSTEM，但系统时区经常变
很多运维习惯写 default-time-zone = SYSTEM，觉得“省事”。但 Linux 系统时区可能被 timedatectl set-timezone、容器镜像基础层、云主机模板悄悄改掉，MySQL 不重启就不会重新读取，导致 @@global.time_zone 滞后于真实系统时区。
- 生产环境务必写死 IANA 时区名：
default-time-zone = '+08:00'或default-time-zone = 'Asia/Shanghai' - 改完
my.cnf后必须重启 MySQL（SET GLOBAL改不了这个参数） - 容器部署时，在
ENTRYPOINT里加检查：mysql -e "SELECT @@global.time_zone;" | grep -q '+08:00' || exit 1 - 注意：
Asia/Shanghai和+08:00在夏令时行为上不同（中国不用夏令时，所以等价；但如果你用Europe/Berlin就不能替换成+01:00）
时区问题最难调试的地方在于：它不报错，只悄悄错。同一个 SQL，在你本地终端、CI 流水线、线上 Pod 里执行结果可能各不相同——因为每个环境的系统时区、MySQL 配置、客户端驱动版本、连接参数全都不一样。盯住 @@global.time_zone、@@session.time_zone、客户端连接参数、字段类型这四点，比查日志快得多。
