mysql实际生效时区需查三层：全局、会话、系统，执行select @@global.time_zone, @@session.time_zone, @@system_time_zone;并配合timedatectl确认；永久配置须在my.cnf中设default-time-zone='+08:00'并重启服务，jdbc连接必须显式指定servertimezone=asia/shanghai，且datetime与timestamp行为不同，前者无视时区，后者自动转换。
查清 MySQL 实际生效的时区值
别急着改配置，先确认当前三层时区到底是什么。登录 MySQL 后立即执行：SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;。同时在终端运行：timedatectl | grep "Time zone"。常见陷阱是：@@global.time_zone 返回 SYSTEM，但系统实际时区却是 UTC——这时 MySQL 看似没配错，实则已偏移 8 小时。
修改 my.cnf 并重启 mysqld 才算永久生效
编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，在 [mysqld] 段下写：default-time-zone = '+08:00'。不推荐直接用 Asia/Shanghai，除非你已执行过：mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql，并验证：SELECT COUNT(*) FROM mysql.time_zone_name WHERE Name = 'Asia/Shanghai'; 返回大于 0。Windows 用户直接用 '+08:00' 更稳妥。改完必须执行：sudo systemctl restart mysql，只改配置不重启等于没改。
JDBC 连接串必须显式带 serverTimezone 参数
即使 MySQL 服务端设成 '+08:00'，JDBC 驱动（8.0+）默认仍按 JVM 本地时区解析时间，造成双重转换。连接串里必须包含：?serverTimezone=Asia/Shanghai&useTimezone=true。注意：GMT%2B8 在部分驱动中不被识别，优先用 IANA 名称；spring.datasource.url 必须包含该参数，spring.jackson.time-zone 对数据库层完全无效。
DATETIME 和 TIMESTAMP 的行为差异不能忽略
DATETIME 是纯字面值，time_zone 设置对它完全没影响；TIMESTAMP 存的是 UTC，读写时自动按会话时区转换。线上系统强烈建议统一用 DATETIME，并由应用层明确约定存储语义（比如“全部存 UTC”或“全部存 Asia/Shanghai”）。如果误用 TIMESTAMP 又没统一会话时区，同一个字段在 Navicat、Java 应用、命令行里查出来的时间字面值会各不相同。
最易被忽略的点：历史数据如果用 DATETIME 存了 UTC 时间，但业务一直当北京时间用，此时改服务端时区毫无意义，只能靠 DATE_ADD(created_at, INTERVAL 8 HOUR) 批量修正——而这类修正本身又依赖当前会话时区是否正确。
