在MySQL迁移过程中，减少停机时间是关键目标之一，尤其对于高可用性要求的业务系统。通过合理的策略和工具配合，可以将服务中断控制在分钟级甚至更低。核心思路是尽量避免“一次性全量迁移+长时间停写”，转而采用增量同步与平滑切换的方式。
使用主从复制实现增量同步
利用MySQL原生的主从复制机制，在迁移前搭建新旧库之间的复制关系，能大幅降低最终停机窗口。
在源数据库启用binlog，并配置唯一server-id 将目标MySQL实例配置为源库的从库，开始同步数据 持续监控复制延迟（Seconds_Behind_Master），确保追平进度 在最后一次切换前，短暂停止应用写入，等待从库完全同步这种方式下，实际停机时间主要用于验证数据一致性和切换DNS或连接地址，通常只需数秒到几分钟。
使用Percona Toolkit进行在线迁移
pt-online-schema-change 和 pt-table-sync 是减少迁移影响的有效工具。
使用 pt-online-schema-change 可在不锁表的情况下修改结构并迁移数据 通过 pt-table-sync 校验并修复主从间的数据差异 适合结构复杂或数据量大的单表迁移场景这些工具基于触发器和chunk分片机制，在线完成数据拷贝与对比，极大降低对业务的影响。
双写过渡与流量切换
对于跨机房或异构环境迁移，可采用双写方案实现无缝过渡。
在应用层同时向新旧数据库写入数据，保证两边数据一致 先读旧库，逐步将读请求切到新库 确认稳定后关闭旧库写入，完成迁移该方法几乎无停机，但需开发配合改造写逻辑，并注意处理异常回滚。
提前准备与风险控制
减少停机不只是技术操作，也依赖充分的前置准备。
提前测试全量导入速度，评估网络带宽瓶颈 压缩传输过程，如使用mydumper + myloader配合压缩参数 制定回滚方案，备份切换前状态 在低峰期执行最终切换动作良好的预案能让迁移更可控，即使出现问题也能快速恢复。
基本上就这些。关键是用好复制机制、工具辅助和流程设计，把“停机”压缩成一个短暂的验证窗口，而不是漫长的迁移过程。
