备份恢复后时间戳错乱主因是时区链路断裂，需核查服务端、连接串、字段类型三者一致性，并执行SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone确认实际生效时区。
备份恢复后时间戳错乱，八成是时区链路断了——服务端、连接串、字段类型三者没对齐，光改default-time-zone基本没用。
查清恢复后 MySQL 实际生效的时区值
备份恢复不等于配置继承，my.cnf里的default-time-zone可能没生效，或被容器/云环境覆盖。必须登录后立刻执行：
SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;
常见陷阱：
-
@@global.time_zone返回SYSTEM，但@@system_time_zone是UTC（比如 Docker 镜像没挂载/etc/localtime） - 恢复后的实例仍沿用旧系统时区，而新宿主机已改成
Asia/Shanghai，但 MySQL 没重读 - 执行过
SET GLOBAL time_zone = '+08:00'，但没写入配置文件，重启即失效
确认备份前建表语句里时间字段是 TIMESTAMP 还是 DATETIME
这是决定修复路径的关键分水岭：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果是
TIMESTAMP：恢复后所有值仍是 UTC 存储，但展示取决于当前会话time_zone。只要会话时区一变，查出来就“跳” - 如果是
DATETIME：值本身没变，错只出在写入时——比如备份前应用用东八区时间字符串插入，但当时 JDBC 连接串漏了serverTimezone，导致存进的是错误字面值 - 混合使用更危险：同一张表里
created_at是DATETIME、updated_at是TIMESTAMP，恢复后一个不变、一个随会话跳，排序和范围查询直接失效
JDBC 连接串必须带 serverTimezone，且不能依赖 JVM 时区
MySQL 8.0+ 驱动默认不信任服务端声明的时区，即使你把default-time-zone设成+08:00，驱动仍会按本地 JVM 时区解析TIMESTAMP字段，造成双重转换：
- 错误写法：
jdbc:mysql://host/db?useUnicode=true（缺serverTimezone） - 正确写法：
jdbc:mysql://host/db?serverTimezone=Asia/Shanghai&useTimezone=true - 别用
GMT%2B8：部分驱动版本不识别 URL 编码偏移量，优先用 IANA 名称 - Spring Boot 用户注意：
spring.jackson.time-zone或-Duser.timezone对数据库层完全无效，必须塞进spring.datasource.url
历史数据偏差不能靠改配置“自动修正”
恢复后发现老数据小时数不对，说明写入时就错了。这时候改time_zone只会让问题更隐蔽：
- 如果原先是
TIMESTAMP但写入时用了错误时区（如 JVM 是 UTC 却当东八区传），现在统一设为+08:00，查出来反而更不准 - 如果全是
DATETIME且字面值错（比如存了'2024-01-01 10:00:00'本意是东八区，结果按 UTC 存了），只能用DATE_ADD(created_at, INTERVAL 8 HOUR)批量修正 - 慎用
CONVERT_TZ()：它依赖mysql.time_zone*表，而很多生产环境根本没加载时区表，CONVERT_TZ('2024-01-01 10:00:00', 'UTC', 'Asia/Shanghai')会返回NULL
最稳妥的做法是：恢复后立刻用真实业务 SQL 查几条关键记录，比对 NOW() 和字段值的逻辑关系，而不是只看单个字段是否“看起来像北京时间”。
