确认源库和目标库的版本兼容性
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失败。
