TIMESTAMP字段迁移后时间错乱是因MySQL 8.0时区处理逻辑变更：5.7自动转UTC存取，8.0在explicit_defaults_for_timestamp=ON下不再隐式补默认值且转换更严格，导致同一数据展示差8小时；需查INFORMATION_SCHEMA定位未显式定义默认值的TIMESTAMP字段，显式添加DEFAULT CURRENT_TIMESTAMP等约束，或改用DATETIME类型，并导出导入时统一使用--tz-utc确保时区一致。
为什么TIMESTAMP字段在迁移后时间显示错乱？
不是数据丢了，是MySQL 8.0对TIMESTAMP的时区处理逻辑变了。5.7默认把TIMESTAMP值转成UTC存、再按会话时区取；8.0在explicit_defaults_for_timestamp=ON（默认）下不再自动补CURRENT_TIMESTAMP，且隐式转换行为更严格。同一行数据在5.7里显示“2025-06-01 14:30”，到8.0可能变成“2025-06-01 06:30”——差的就是时区偏移。
如何快速定位哪些表受时区影响？
别猜，直接查INFORMATION_SCHEMA.COLUMNS找所有未显式声明默认行为的TIMESTAMP字段：
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE DATA_TYPE = 'timestamp' AND COLUMN_DEFAULT IS NULL AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');- 对结果中的每个表，执行
SHOW CREATE TABLE，确认是否含DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP或DEFAULT '0000-00-00 00:00:00' - 重点盯
created_at、updated_at这类高频字段，它们最常被隐式绑定时区逻辑
修复时区错乱必须改表结构，不能只调参数
临时设SET time_zone = '+08:00'或改my.cnf里的default-time-zone只能缓解查询显示，无法修正已存数据的UTC映射关系。真正要做的，是让字段定义自包含时区语义：
- 对需要自动更新的字段，显式加
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 对仅记录创建时间的字段，用
DEFAULT CURRENT_TIMESTAMP，避免NULL或零值 - 若业务要求存储本地时间（不转UTC），改用
DATETIME类型，它不参与时区转换 - 执行
ALTER TABLE t MODIFY COLUMN created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP;后，已有数据不会重算，但新插入/更新行为就可控了
导入SQL文件前必须检查时区一致性
mysqldump导出时若没指定时区，会按导出端会话时区写入时间字面量。例如5.7服务器设time_zone='+00:00'，导出的'2025-06-01 14:30:00'其实是UTC时间；若8.0目标库设time_zone='+08:00'，直接导入就会多加8小时。
- 导出时强制统一时区：
mysqldump --tz-utc --default-character-set=utf8mb4 -u root -p mydb > mydb.sql（--tz-utc确保时间按UTC写入） - 导入前确认目标库时区：
SELECT @@global.time_zone, @@session.time_zone;，建议设为SYSTEM或显式+00:00 - 若已导入且时间全偏移，需用
UPDATE语句批量修正，例如：UPDATE t SET created_at = DATE_ADD(created_at, INTERVAL 8 HOUR) WHERE ...;（按实际偏差调整）
TIMESTAMP字段的修复必须在数据导入前完成，否则错乱时间会固化进8.0的数据页，后续靠SQL函数修正成本极高。 
