17370845950

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;，确认与预期一致

修复已错乱的时间数据（谨慎操作）

如果数据已写入错误（如本该是 2025-05-01 10:00:00 却存成 2025-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;
• 仅适用于所有记录统一偏移且无夏令时干扰的场景
• 更安全做法：从源库重新导出，用正确时区参数导入

不复杂但容易忽略，核心就三点：服务端时区对齐、字段类型行为清楚、连接层不越权干预。