中小规模迁移直接用 mysqldump
，但必须加 --single-transaction
数据量在 500 万行以内、目标库仍是 MySQL、不跨版本（如 5.7→8.0）时，
mysqldump是最稳的选择——它不依赖额外组件，脚本可审计，失败后重试成本低。
关键不是“能不能用”，而是“怎么用才不出错”：
•
--single-transaction对 InnoDB 表能保证一致性快照，避免锁表；但对 MyISAM 表无效，线上务必先查引擎：
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='yourdb';
• 默认不导出用户权限和 DEFINER，导入后视图/存储过程可能报
View 'xxx' references invalid table(s)，需手动补
mysqldump -u root -p --no-data --skip-triggers mysql.user > users.sql或加
--skip-definer
• 导入前必须先建库：
mysql -e "CREATE DATABASE IF NOT EXISTS targetdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"，否则会报错且静默失败
超 500 万行或需断点续传，换 mydumper
/myloader
当单表超千万行、或备份耗时超过业务容忍窗口（比如 >1 小时），
mysqldump的单线程瓶颈就暴露了。这时
mydumper能提速 3–10 倍，核心靠三件事：多线程分表导出、事务快照隔离、压缩传输。
实操注意点：
• 备份命令里加
--skip-definer，否则导入视图时大概率报错
• 外键强依赖的库（比如订单→订单项→商品），
myloader不保证建表顺序，得提前关外键检查：
SET FOREIGN_KEY_CHECKS=0;，导入完再开
• 它不导出触发器，迁移后要单独用
SHOW CREATE TRIGGER手动补
• 断点续传靠的是目录结构 + 文件名时间戳，别手动删中间文件，否则
myloader会跳过已存在表
跨数据库迁移（MySQL→PostgreSQL/SQL Server/Oracle）别碰 mysqldump
SQL 文件
直接把
mysqldump出来的 SQL 拿去改语法，等于埋雷：字段类型映射错（比如
TINYINT(1)被当成布尔）、函数不兼容（
GROUP_CONCATvs
STRING_AGG）、权限模型差异（MySQL 用户粒度 vs SQL Server schema 粒度）。
更靠谱的路径是：
• MySQL→PostgreSQL：用
pgloader，它内置类型转换规则，支持从配置文件定义映射逻辑，例如把
datetime映射为
timestamptz
• MySQL→SQL Server：用微软官方的
SSMA for MySQL，它能生成评估报表，标出所有无法自动转换的对象（比如自定义函数），比人工扫 SQL 高效得多
• MySQL→OceanBase：必须走 OMS 工具，因为 OceanBase 的分区策略、租户模型、SQL 兼容层和 MySQL 有本质差异，手工改几乎不可行
VMware 替换或上云场景，优先考虑 DTS 类平台工具
如果迁移不是“导出再导入”，而是涉及 VMware 下线、混合云切换、或要求业务零停机，硬写脚本风险太高。像深信服 DTS、腾讯云 DTS 这类工具，底层其实是封装了
mydumper+ 主从 BINLOG 增量同步，但省去了你配 GTID、调
binlog_format=ROW、处理位点偏移这些易错环节。
前提是源库满足两个硬条件：
• 开启
binlog且格式为
ROW（
SHOW VARIABLES LIKE 'binlog_format';）
• 推荐开启 GTID（
gtid_mode=ON），否则增量同步容易断连后无法续传
这类工具真正省心的地方，是把“全量校验+增量追平+平滑切流”做成原子操作，而不是让你自己写脚本拼接三个阶段
工具选型本质是权衡：数据量、一致性要求、目标平台、运维能力。最容易被忽略的不是“哪个工具快”，而是“迁移后应用连得上吗”——比如 MySQL 8.0 默认
caching_sha2_password插件，旧 JDBC 驱动连不上；或者 OceanBase 迁移后没调
compatible_mysql_version参数，
GROUP BY报错。迁移完成那一刻，只是验证的开始。
