mysql时区不一致导致时间快8小时，根源在于服务端、连接层、应用层时区未统一；需同步配置服务端（my.cnf或set global）、客户端（如jdbc的servertimezone）及时区敏感字段类型（优先datetime）。
MySQL服务端时区设置为UTC导致时间快8小时
现象是：应用写入 NOW() 或 CURRENT_TIMESTAMP，查出来比本地时间快8小时（比如你在北京，存进去显示 16:00，实际才 08:00）。这通常是因为 MySQL 服务端全局时区设成了 UTC，而你的应用或连接没做适配。
根本原因不是“MySQL错了”，而是服务端、连接层、应用层三者时区不统一。最直接的解法是让服务端时区和业务所在地一致（如 'Asia/Shanghai'），但要注意：改完会影响所有连接，且需重启或动态生效权限。
- 检查当前服务端时区：
SELECT @@global.time_zone, @@session.time_zone; - 临时修改（重启失效）：
SET GLOBAL time_zone = '+08:00';或SET GLOBAL time_zone = 'Asia/Shanghai'; - 永久修改：在
my.cnf的[mysqld]段下加default-time-zone = '+08:00'，然后重启 MySQL - 注意：
SET GLOBAL需要SUPER权限；'Asia/Shanghai'依赖系统 tzdata，某些 Docker 镜像或精简版 Linux 可能不带该时区名，优先用'+08:00'
客户端连接未指定时区，导致 NOW() 返回值错乱
即使服务端设对了，如果 JDBC、Python 的 pymysql、Node.js 的 mysql2 等客户端没显式声明时区，它们可能按本地系统时区解析时间字段，或把传入的时间当作 UTC 处理，造成“写入慢8小时”或“查询快8小时”。
这不是 MySQL 的锅，是连接层把时间戳解释错了。关键点在于：MySQL 的 TIMESTAMP 类型会自动转成服务端时区存储、再转回连接时区返回；而 DATETIME 是“原样存原样取”，不涉及时区转换。
- JDBC 连接串必须加参数：
?serverTimezone=Asia/Shanghai&useTimezone=true（MySQL 8.0+ 推荐用serverTimezone，旧版用useJDBCCompliantTimezoneShift） - Python pymysql：初始化连接时传
timezone='+08:00'或init_command="SET time_zone = '+08:00'" - PHP PDO：连接后立即执行
SET time_zone = '+08:00' - 避免混用
TIMESTAMP和DATETIME字段处理同一业务逻辑——前者自动转换，后者不转换，容易埋坑
ALTER TABLE 修改字段类型引发隐式时区转换
当你对已有 TIMESTAMP 字段执行 ALTER TABLE ... MODIFY COLUMN（哪怕只是加个注释或调整长度），MySQL 会触发一次“值重写”。如果此时连接时区和服务端时区不一致，这个重写过程可能把时间值错误地转换一次，导致数据偏移8小时。
这种问题往往在迁移或 DDL 变更后才发现，而且不可逆（原始值已丢）。本质是 MySQL 在 ALTER 期间把存储的 UTC 值按当前 session 时区解读，再存回去。
- 操作前务必确认：
SELECT @@session.time_zone;是否等于@@global.time_zone - 安全做法：先执行
SET time_zone = '+00:00';（切到 UTC），再做 ALTER；或者干脆用DATETIME替代TIMESTAMP，规避自动转换 - 已有数据出错？只能靠日志或备份恢复，MySQL 不记录这类转换前的原始字节值
-
TIMESTAMP的自动初始化/更新行为（如DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP）也受 session 时区影响，别在跨时区集群里依赖它
Java 应用里 LocalDateTime 存进 TIMESTAMP 字段出现8小时偏差
这是典型的类型误用：Java 的 LocalDateTime 没有时区信息，但你把它塞进 MySQL 的 TIMESTAMP 字段，JDBC 驱动会默认按 JVM 本地时区解释这个“无时区时间”，再转成 UTC 存进数据库。结果就是：JVM 在东八区，驱动认为 2024-01-01 12:00:00 是北京时间，转成 UTC 就存成 2024-01-01 04:00:00，查出来自然少8小时。
- 正确做法一（推荐）：Java 侧统一用
ZonedDateTime或Instant，明确携带时区语义 - 正确做法二：数据库字段改用
DATETIME，JDBC 写入LocalDateTime时不会做时区转换 - 错误做法：在 SQL 里硬写
CONVERT_TZ(NOW(), '+00:00', '+08:00')补偿——治标不治本，且不同连接时区下结果不稳定 - Spring Boot 2.2+ 默认启用
spring.jpa.properties.hibernate.jdbc.time_zone=GMT%2B8，但仅影响 JPA 层，原生 JDBC 还得单独配
my.cnf 就万事大吉，却忘了连接池里的老连接还带着旧的 time_zone session 变量，它们会继续错下去，直到被回收。
