MySQL迁移后时间异常主因是时区不一致或TIMESTAMP/DATETIME使用不当；需统一服务端时区为+08:00，导出时用--tz-utc=false，连接层显式声明serverTimezone，优先选用DATETIME。
MySQL迁移后时间字段异常，多数是因为时区设置不一致或时间类型使用不当导致的。重点检查源库和目标库的时区配置、TIMESTAMP与DATETIME的行为差异，以及连接层是否强制转换了时间值。
确认并统一 MySQL 服务端时区
MySQL 的 TIMESTAMP 类型会自动按服务器时区转换存储和查询，而 DATETIME 不受时区影响。迁移后若发现时间偏移（如全晚8小时），极可能是目标库时区设为 SYSTEM（即系统默认时区），而源库运行在 +08:00，但系统实际是 UTC。
- 查当前时区：
SELECT @@time_zone, @@system_time_zone; - 临时设为东八区：
SET GLOBAL time_zone = '+08:00'; - 永久生效：在
my.cnf中添加default-time-zone = '+08:00'，重启 MySQL - 注意：修改后需重启服务才对已存在
TIMESTAMP字段的读写行为生效
区分 TIMESTAMP 和 DATETIME 的迁移逻辑
两者底层处理机制不同：TIMESTAMP 存的是 UTC 时间戳，显示时转为会话时区；DATETIME 存的是字面值，不做转换。迁移时若用 mysqldump 默认导出，TIMESTAMP 值会被转成会话时区下的字符串再插入，容易出错。
- 导出时显式指定时区：
mysqldump --tz-utc=false -u user db > dump.sql，避免自动转 UTC - 导入前确保客户端会话时区一致：
SET time_zone = '+08:00'; - 新项目建议优先用
DATETIME，除非真需要自动时区转换
检查应用连接层的时区设置
即使数据库时区正确，JDBC、Python MySQLdb、PHP mysqli 等驱动也可能在连接串里强制指定时区，覆盖服务端设置。
- JDBC 示例：
?serverTimezone=Asia/Shanghai&useTimezone=true必须显式声明，否则可能按 JVM 本地时区解析 - Python PyMySQL：
connect(..., autocommit=True, timezone='+08:00') - PHP PDO：
mysql:charset=utf8mb4;timezone=+08:00 - 验证方式：连接后执行
SELECT @@session.time_zone;，确认与预期一致
修复已错乱的时间数据（谨慎操作）
如果数据已写入错误（如本该是 2024-05-01 10:00:00 却存成 2024-05-01 02:00:00），需根据错因反向补偿。常见情况是源库在 +08:00，目标库误设为 UTC，导致 TIMESTAMP 多减了 8 小时。
- 先备份表：
CREATE TABLE t_bak AS SELECT * FROM t; - 对
TIMESTAMP字段批量加回时差：UPDATE t SET ts_col = ts_col + INTERVAL 8 HOUR; - 仅适用于所有记录统一偏移且无夏令时干扰的场景
- 更安全做法：从源库重新导出，用正确时区参数导入
不复杂但容易忽略，核心就三点：服务端时区对齐、字段类型行为清楚、连接层不越权干预。
