MySQL 迁移不是简单复制文件，核心是保证数据一致性、服务连续性和权限完整性。关键不在“怎么搬”，而在“搬得稳、用得准、切得平”。
一、迁移前必须做的三件事
不检查清楚就动手，90% 的问题出在这一步。
- 确认版本兼容性：新旧 MySQL 版本不能跨大版本跳跃（如 5.7 → 8.0 需注意密码认证插件、系统表结构变化），建议先在测试环境验证 SQL 兼容性；
- 梳理依赖与权限：导出所有用户、角色、权限（
select CONCAT('SHOW GRANTS for ''',user,'''@''',host,''';') FROM mysql.user;+ 手动执行每条），特别注意 DEFINER、存储过程、事件调度器； - 停写或锁表评估：业务能否接受停机？若不能，需提前规划主从切换或使用 pt-table-checksum + pt-table-sync 校验，避免主从延迟导致数据不一致。
二、两种主流迁移方式选型
根据数据量、停机窗口、网络条件决定路径：
- 逻辑迁移（mysqldump / mydumper）：适合中小规模（–single-transaction –routines –triggers –events –set-gtid-purged=OFF（GTID 环境下）；
- 物理迁移（xtrabackup / rsync + binlog）：适合大库（>100GB）、同版本同架构、要求快速恢复场景； 注意：xtrabackup 备份后需
--prepare，还原前清空目标 datadir，且新实例配置要与原库对齐（如 innodb_page_size、lower_case_table_names）。
三、迁移中必须校验的三个层面
只看“导入完成”不等于迁移成功，必须逐层验证：
- 结构层：对比表数量、字段类型、索引名、外键约束（可用
mysqldbcompare或自定义 SQL 查询 information_schema）； - 数据层：抽样比对行数（
SELECT count(*)）、关键业务表 checksum（SELECT CRC32(GROUP_CONCAT(...))或用 pt-table-checksum）； - 行为层：执行典型业务 SQL（含事务、联合查询、子查询），观察执行计划是否变化、是否报错、响应时间是否突增。
四、切流与收尾关键动作
上线不是“改个 IP 就完事”，容易被忽略但极其重要：
- dns/连接池缓存清理：更新应用配置前，确认连接池（如 HikariCP、Druid）已清空旧连接，避免复用残留连接；
- binlog 位点对齐（主从切换场景）：新主库开启 binlog 后，确保从库追上原主最后位置，再执行
STOP SLAVE; RESET SLAVE ALL;并重新指向新主； - 旧库保留观察期：至少保留 3–7 天只读状态，监控新库慢日志、错误日志、QPS/TPS 趋势，确认无异常后再下线。
不复杂但容易忽略——迁移本质是风险控制过程，每一步都要有回退方案和验证动作。