MySQL 数据迁移是数据库运维中的高频操作，无论是升级硬件、更换云厂商，还是拆分库表，都离不开数据迁移工具。但工具选型不当或操作疏忽，轻则迁移失败，重则数据丢失。本文从典型场景出发，分析主流迁移工具的使用步骤、取舍与注意事项。
场景一：小数据量全量迁移——mysqldump 的适用边界
当数据量在几十 GB 以内，且允许短暂停机时，mysqldump 是最直接的选择。它逻辑备份的特性使得迁移后可以跨版本、跨平台恢复。基本步骤是：先在源库执行 mysqldump --single-transaction --set-gtid-purged=OFF -u user -p dbname > backup.sql，再将备份文件传输到目标库，执行 mysql -u user -p dbname < backup.sql。使用 --single-transaction 可在 InnoDB 下获得一致性快照，避免锁表。但需注意：mysqldump 生成的 SQL 文件在恢复时可能因索引、外键顺序导致性能问题，建议恢复前关闭外键检查（SET FOREIGN_KEY_CHECKS=0）。此外，--set-gtid-purged=OFF 可避免 GTID 冲突，但若源库启用了 GTID，迁移后需要重置 GTID 信息。
场景二：大数据量离线迁移——物理备份工具
当数据量达到 TB 级，mysqldump 的逻辑导出会消耗大量时间与资源。此时应使用物理备份工具，如 Percona XtraBackup。它直接复制数据文件，速度远快于逻辑备份，且支持增量备份。典型步骤：在源库执行 xtrabackup --backup --target-dir=/backup/base，然后 xtrabackup --prepare --target-dir=/backup/base 使备份可恢复，最后将备份目录复制到目标库，并恢复权限与配置文件。注意事项：物理备份要求源库与目标库的版本、操作系统架构尽量一致，否则可能因数据文件格式不兼容导致启动失败。另外，XtraBackup 在备份过程中会占用较多磁盘 I/O，建议在业务低峰期执行。
场景三：在线迁移不停机——基于 Binlog 的同步工具
若业务不允许停机，则需要在线迁移方案。常见做法是使用 MySQL 主从复制或第三方工具如 pt-osc、gh-ost 进行在线表结构变更，但数据迁移通常采用“全量+增量”方式。例如使用 mysqldump 导出全量数据，同时开启 Binlog，然后通过 mysqlbinlog 解析增量日志，或直接配置主从同步。具体步骤：先记录当前 Binlog 位置（SHOW MASTER STATUS），导出全量数据，导入目标库后，再配置目标库为源库的从库，追平增量。注意事项：Binlog 格式必须为 ROW，且源库需开启 log_bin 和 binlog_format=ROW。若迁移过程中表结构发生变化，可能导致同步中断。此外，网络延迟可能造成复制延迟，需监控 Seconds_Behind_Master 指标。
迁移中的常见误区与失败条件
不少团队在迁移时忽视字符集与排序规则的一致性，导致导入后中文乱码或索引失效。建议导出时使用 --default-character-set=utf8mb4，导入前确认目标库的字符集设置。另一个误区是忽略外键与触发器，mysqldump 默认会导出，但恢复顺序可能因外键依赖而失败，需使用 --disable-foreign-key-checks 或手动调整。此外，迁移后务必校验数据完整性，例如对比表行数、校验和（CHECKSUM TABLE），避免静默数据损坏。若迁移过程中出现网络中断或磁盘写满，可能导致备份文件不完整，因此应在迁移前检查磁盘空间，并启用 --compress 选项减小传输体积。
工具选型的取舍与性能考量
选择迁移工具时，需权衡速度、一致性与易用性。mysqldump 通用性强，但速度慢；XtraBackup 速度快，但要求环境相近；基于 Binlog 的同步工具适合在线迁移，但配置复杂。对于跨云迁移，网络带宽往往是瓶颈，可通过压缩传输或使用并行导出工具（如 mydumper）提升效率。mydumper 支持多线程导出，可显著缩短迁移时间，但恢复时需注意导入工具（myloader）的兼容性。无论选择哪种工具，都应先在测试环境演练，并制定回滚方案。
日志与监控在迁移中的作用
迁移过程中的日志记录是排查问题的关键。正如 OWASP 日志安全速查表所强调，日志应包含足够的事件上下文，以便事后分析。在迁移时，应开启 MySQL 的 general log 或 error log，记录所有 SQL 与错误信息。同时，利用监控工具跟踪迁移进度与系统资源，如磁盘 I/O、网络吞吐量。OpenTelemetry 日志规范指出，日志与追踪、指标结合能提供更完整的可观测性，因此在迁移完成后，应检查应用日志中是否有连接错误或超时记录。Python 的 logging 模块展示了层级化日志管理的优势，类似的，迁移脚本也应采用结构化日志，便于过滤与分析。
迁移后的验证与收尾
数据导入完成后，必须进行业务验证。首先检查数据库服务状态，执行 SHOW DATABASES 确认库表存在。其次，运行典型查询，对比源库与目标库的结果集。若涉及自增主键，需确认 AUTO_INCREMENT 值是否一致。最后，更新应用连接串，并逐步切流。若使用主从同步，需在切换后解除主从关系（STOP SLAVE; RESET SLAVE ALL;）。切勿在未验证的情况下直接下线源库，建议保留一段时间的只读访问，以便回退。
参考资料
延伸阅读