最轻量又真实的MySQL主版本升级测试方式是用旧版mysqldump导出全量数据（含--routines --triggers --events --single-transaction --set-gtid-purged=OFF），再用新版mysql客户端导入隔离实例，重点捕获ERROR 1231、1067、3719等兼容性错误，并通过pt-upgrade回放慢日志验证查询一致性，同时检查GTID集合、SQL线程状态及事务隔离级别是否符合预期。
怎么用mysqldump导出再导入模拟主从版本差异
直接在生产从库上升级风险太高，最轻量又真实的测试方式是：用旧版本mysqldump导出全量数据（含存储过程、触发器、事件），再用新版本mysql客户端导入到隔离实例中，观察报错类型和行为变化。
必须加这几个参数：--routines --triggers --events --single-transaction --set-gtid-purged=OFF。漏掉--set-gtid-purged=OFF会导致导入后GTID位点污染，后续无法复现主从切换场景。
-
ERROR 1231 (42000)：大概率是sql_mode变更（如STRICT_TRANS_TABLES启用） -
ERROR 1067 (42000)：时间字段默认值非法（0000-00-00被拒绝） -
ERROR 3719 (HY000)：字符集问题（utf8mb3已弃用，需提前批量改utf8mb4） - 别跳过
--triggers——有些触发器里用了OLD.table_name，在MySQL 8.0.19+中受限
为什么不能只跑mysql_upgrade --dry-run就认为兼容
mysql_upgrade --dry-run只检查系统表结构是否缺失，完全不覆盖业务SQL行为变化。比如GROUP BY在MySQL 8.0默认开启ONLY_FULL_GROUP_BY，旧SQL可能直接报错；JSON_EXTRACT返回类型在8.0.29后也变了，但--dry-run不会暴露这些。
真正要验证的是查询结果一致性。推荐用pt-upgrade回放生产慢日志，在新旧实例上比对输出：
-
--run-time=300控制回放时长，避免拖太久 -
--query-review-table需提前在两个实例建好对比表 - 特别标记
ERROR 1292 (22007)（隐式截断转错误），这类语句在5.7能跑通，8.0会中断复制
如何验证从库升级后复制是否真能追平
从库启动新版本后，START SLAVE不是终点，必须确认复制状态真正稳定。光看Seconds_Behind_Master = 0不够，它可能只是瞬时值。
关键检查项要一起看：
-
Slave_SQL_Running_State显示Slave has read all relay log（不是Waiting for master to send event） -
Retrieved_Gtid_Set和Executed_Gtid_Set完全一致，用SELECT GTID_SUBSET(@@global.gtid_executed, 'xxx')=1校验 -
read_only = ON且super_read_only = ON已生效（SHOW VARIABLES LIKE '%read_only%'） - 执行
SELECT * FROM information_schema.INNODB_TRX，确认trx_isolation是READ-COMMITTED（8.0默认），不是旧版REPEATABLE-READ
降级测试最容易忽略的binlog兼容性陷阱
从8.0切回5.7失败，90%是因为binlog里混入了新event类型。比如8.0写的ANONYMOUS_GTID_LOG_EVENT，5.7的mysqlbinlog根本解析不了，复制直接中断。
降级前必须做三件事：
- 升级窗口内禁止
ALTER TABLE ... ALGORITHM=INSTANT——5.7回放会报Unknown algorithm - 把
binlog_format临时设为MIXED或STATEMENT（避免ROW格式下隐式类型转换差异） - 备份时用
mysqldump --skip-triggers --set-gtid-purged=OFF，否则GTID位点信息会污染旧环境恢复
真正的难点不在升级动作本身，而在复制链路里那些看不见的event格式、GTID集合边界、以及SQL线程对语法的容忍度——这些细节一旦错配，数据就静默不一致了。
