MySQL迁移时业务停机过长会直接影响收入和用户体验，想要把停机时间压到最低，核心思路是让数据提前就位、最后只做极短切换。下面介绍几种在 production 环境中比较成熟的优化方案。
一、基于主从同步的迁移方案
这是最常用的做法。先给源库搭建一个从库，把数据全量加增量同步到目标机器，等延迟接近零后再断开业务并切到新库。
基本步骤
- 在目标机部署 MySQL 并配置为源库从节点
- 通过 mysqldump 或 xtrabackup 做全量初始化
- 观察 Seconds_Behind_Master 直到延迟为 0
- 业务低峰期停写，确认无延迟后修改连接配置
示例：用 xtrabackup 做全量备并恢复
# 在源库生成备份 xtrabackup --backup --target-dir=/data/backup --user=root --password=pass # 在目标库准备并恢复 xtrabackup --prepare --target-dir=/data/backup xtrabackup --copy-back --target-dir=/data/backup
二、双写加增量校验方案
对停机极度敏感的系统，可以采用双写：业务同时写老库和新库，用消息队列或中间件保证顺序。迁移后期再用增量对比工具修平差异。
双写伪代码
public void saveOrder(Order o) {
oldDao.insert(o); // 写老库
try {
newDao.insert(o); // 写新库
} catch (Exception e) {
mq.send("fix_new_db", o); // 失败丢队列补偿
}
}
三、使用在线迁移工具
像 gh-ost、canal 这类工具能解析 binlog 做实时同步，避免锁表，适合大表迁移。
| 工具 | 原理 | 停机时间 |
|---|---|---|
| canal | 模拟从库读 binlog | 秒级 |
| gh-ost | 无触发器改表同步 | 几乎为零 |
四、割接前检查清单
任何迁移方案上线前，都要在灰度环境跑通一遍，并准备好回滚脚本。
关键检查项：
- 目标库账号权限与源库一致
- 自增主键最大值无冲突
- 业务连接串支持动态刷新
合理组合上述 MySQL 迁移优化方案，可以把停机时间从小时级降到分钟甚至秒级，保障业务平滑过渡。