迁移大数据量的 MySQL 数据库，关键在于减少停机时间、保证数据一致性，并合理利用工具和策略。不能简单使用 mysqldump 全量导出导入，否则耗时太长且影响线上服务。以下是几种高效可行的方法：
1. 使用物理备份工具（如 Percona XtraBackup）
对于大数据库（几十GB 到 TB 级），物理备份比逻辑备份快得多。
XtraBackup 特点： 支持热备份，不锁表，不影响线上业务 备份和恢复速度快，直接复制数据文件 支持增量备份，可用于分阶段迁移操作流程：
在源库安装并执行 XtraBackup 进行全量备份 将备份文件传输到目标服务器 在目标服务器恢复备份 如有需要，再通过 binlog 增补最后一次变更（实现准实时同步）2. 利用主从复制方式迁移
通过配置主从复制，把新库作为从库同步数据，等数据追平后切换流量。
步骤如下： 在目标机器部署新 MySQL 实例，暂作从库 启用源库的 binlog，设置 server-id，开启 GTID（推荐） 使用 XtraBackup 或部分逻辑导出初始化从库数据 配置 CHANGE MASTER TO 指向源库 启动复制：START SLAVE 监控复制延迟（SHOW SLAVE STATUS），直到 SQL thread 和 I/O thread 追平 短暂停写源库，确认无延迟后，切流量到新库这种方法能极大缩短停机窗口，适合生产环境迁移。
3. 分库分表 + 并行迁移
如果单表特别大（比如超过 100G），可考虑按条件拆分迁移。
例如： 按时间范围导出：WHERE create_time BETWEEN '2023-01-01' AND '2023-06-01' 使用多个线程并行导出不同分区 目标库提前建好表结构和索引（可先不建二级索引，导入后再建） 导入完成后统一校验数据量和关键指标工具可用 mydumper / myloader，它支持多线程逻辑备份与恢复，比 mysqldump 快很多。
4. 增量数据同步保障一致性
在全量迁移过程中，源库仍在写入。必须捕获这些变化。
方案包括： 启用 binlog，记录全量备份开始时的位点（或 GTID） 迁移期间持续收集 binlog（可用 mysqlbinlog 远程拉取或本地归档） 全量导入完成后，回放增量 binlog 补齐数据 或者使用中间件（如 Canal、Maxwell）将变更同步到新库这样可以做到“接近零停机”切换。
基本上就这些。选哪种方法取决于你的停机容忍度、数据量大小和架构灵活性。XtraBackup + 主从复制是最常见、最稳妥的大数据量迁移路径。
