确保跨版本迁移时TIMESTAMP行为一致，核心是统一explicit_defaults_for_timestamp取值、表结构定义及SQL_MODE；MySQL 5.6/5.7默认OFF而8.0.2+默认ON，需在目标库配置文件中设为OFF并重启，建表必须显式声明所有TIMESTAMP属性，同步前须验证INSERT/UPDATE逻辑并检查SQL_MODE与物理参数兼容性。
要确保跨版本迁移时 TIMESTAMP 行为一致，核心是让源库和目标库在 explicit_defaults_for_timestamp 的取值、表结构定义方式、以及 SQL_MODE 配合上保持统一。这个参数不是“设了就完事”，它直接影响建表逻辑和 INSERT/UPDATE 语义，尤其在 5.6/5.7 → 8.0 迁移中极易引发隐性故障。
迁移前必须对齐参数值
MySQL 5.6 和 5.7 默认为 OFF，而 8.0.2+ 默认为 ON。若不做干预，同一建表语句在两端生成的表结构会不同：
- 当
explicit_defaults_for_timestamp = OFF：第一个 TIMESTAMP 列自动获得DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，其余未声明的 TIMESTAMP 列默认变成NOT NULL DEFAULT '0000-00-00 00:00:00' - 当
explicit_defaults_for_timestamp = ON：所有 TIMESTAMP 列都按显式定义处理；没写NOT NULL就允许 NULL；没写DEFAULT就不设默认值；插入 NULL 不会转成当前时间，而是直接报错或存 NULL（取决于是否允许 NULL）
因此，迁移前应在目标实例（尤其是 MySQL 8.0+）的配置文件中明确设置：
[mysqld]explicit_defaults_for_timestamp = OFF
并重启服务。注意：该变量支持动态修改（SET GLOBAL），但仅影响新连接的会话，且部分云数据库可能禁用动态修改，优先走配置文件。
建表语句必须显式声明所有 TIMESTAMP 属性
依赖参数默认行为是最大风险点。无论参数值如何，都应强制在 DDL 中写全关键子句：
- 需要自动更新的列：明确写
timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 仅记录创建时间的列：写
timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP（不加 ON UPDATE） - 允许为空的时间字段：写
timestamp NULL，并在应用层控制赋值逻辑 - 避免使用
DEFAULT '0000-00-00 00:00:00'，尤其当 SQL_MODE 含NO_ZERO_DATE时会报错
这样即使参数值切换，表结构定义和插入行为也不会漂移。
同步或导入时验证数据写入逻辑
参数差异最易暴露在 INSERT 场景中。例如：
INSERT INTO t (ts1, ts2) VALUES (NULL, NULL);- 源库（OFF）：
ts1自动变当前时间，ts2变'0000-00-00 00:00:00'（若允许） - 目标库（ON，且未显式定义）：直接报错
Column 'ts1' cannot be null
建议在迁移预检阶段，抽样执行原始 INSERT/UPDATE 语句，比对返回结果与写入值。若发现不一致，需回溯应用代码或中间件是否隐式依赖了旧版自动填充逻辑。
配套检查 SQL_MODE 和物理兼容性
explicit_defaults_for_timestamp 不是孤立参数。它常与以下设置联动生效：
-
SQL_MODE中若含STRICT_TRANS_TABLES或NO_ZERO_DATE，会进一步限制 '0000-00-00' 类默认值的写入，加剧 OFF 模式下的兼容问题 - 物理备份恢复时，还必须确保
innodb_file_per_table和innodb_page_size与源库一致，否则即使参数对齐，启动也会失败 - 严禁直接拷贝系统库（如 mysql、information_schema）目录，它们在 8.0 中结构已大幅变更
不复杂但容易忽略
