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;仅适用于所有记录统一偏移且无夏令时干扰的场景 更安全做法：从源库重新导出，用正确时区参数导入
不复杂但容易忽略，核心就三点：服务端时区对齐、字段类型行为清楚、连接层不越权干预。
