MySQL跨大版本迁移需验证兼容性、用--single-transaction等参数导出、过滤权限语句导入、GTID模式下正确设置gtid_purged并校验位点对齐。
确认源库和目标库的版本兼容性
MySQL 主版本跨大版本迁移（如 5.7 → 8.0）不是简单 dump/restore 就能完成的，必须提前验证兼容性。8.0 默认启用 sql_mode=STRICT_TRANS_TABLES，而很多老应用依赖宽松模式下的隐式转换，直接还原会报错。
- 用
SELECT VERSION()和SELECT @@sql_mode分别查源库和目标库配置 - 若目标为 8.0，建议在目标库临时关闭严格模式测试：执行
SET GLOBAL sql_mode=''（仅会话级可先加SET SESSION） - 注意 8.0 移除了
mysql_old_password插件、GROUP BY隐式排序等行为，需检查应用 SQL 是否含此类写法
mysqldump 导出时的关键参数组合
默认 mysqldump 不保证一致性，尤其对大表或高并发写入场景，容易导出半截数据。必须组合使用事务与锁策略。
- 对于 InnoDB 表，优先用
--single-transaction：它通过一致性快照避免锁表，但要求所有表都是 InnoDB - 若含 MyISAM 表，必须配合
--lock-all-tables（全局读锁），否则可能损坏逻辑一致性 - 务必加上
--routines --triggers --events，否则存储过程、触发器、事件不会被导出 - 避免用
--skip-extended-insert：虽然便于 diff，但导入速度下降 5–10 倍，生产环境慎用
mysqldump -h source_host -u user -p --single-transaction --routines --triggers --events --databases db1 db2 > backup.sql
导入时跳过权限和系统库语句
直接执行完整 dump 文件到新实例，常因 CREATE USER、GRANT 或对 mysql 库的写入失败——目标库可能已有同名用户，或权限表结构不一致（如 8.0 的 mysql.user 多了 account_locked 字段）。
- 用
grep -v "^CREATE USER\|^GRANT\|^INSERT INTO `mysql`" backup.sql > clean.sql过滤掉权限相关语句 - 导入后单独用
mysql_upgrade（5.7）或mysqld --upgrade=FORCE（8.0）修复系统表 - 用户权限建议用
SELECT CONCAT('CREATE USER ''',user,'''@''',host,''' IDENTIFIED BY ''xxx'';') FROM mysql.user;手动重建，而非复用旧 dump
主从切换前验证 binlog 位点与 GTID 状态
如果迁移目标是作为新主库上线，且原架构依赖主从同步，不能只看数据一致，更要确认复制链路可延续。GTID 模式下，Executed_Gtid_Set 必须包含源库 Retrieved_Gtid_Set 的全部事务。
- 源库执行
SHOW MASTER STATUS记下File和Position；GTID 模式下记Executed_Gtid_Set - 目标库导入完成后，执行
SHOW SLAVE STATUS\G，确认Relay_Master_Log_File和Exec_Master_Log_Pos能对齐源库位点 - 若启用了
gtid_mode=ON，导入前必须在目标库执行SET GLOBAL gtid_purged = 'xxx-xxx-xxx:1-1000';（值来自源库SELECT @@gtid_executed）
GTID 混用传统位点、或者忽略 gtid_purged 设置，会导致后续 CHANGE MASTER 报错 Cannot replicate from member with different server_uuid 或 The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1 失败。
