生产环境下如何使用MySQL Shell进行大规模数据快速迁移？-mysql教程-PHP中文网

mysql shell的util.dumpinstance是生产环境大规模迁移最可控的选择，它不全程锁表、支持一致性快照、能跳过系统库，比mysqldump更适合千亿级场景。

生产环境下如何使用mysql shell进行大规模数据快速迁移？

MySQL Shell 的 util.dumpInstance 是生产环境大规模迁移最可控的选择，它不全程锁表、支持一致性快照、能跳过系统库，比 mysqldump 更适合千亿级场景。

为什么不能直接用 mysqldump 做生产迁移

mysqldump 默认会加 --lock-all-tables 或对每个表单独 LOCK TABLES，在活跃业务下极易引发连接堆积、超时甚至服务雪崩。即使加了 --single-transaction，也只对 InnoDB 有效，且无法规避长事务阻塞快照获取——你看到的“卡住”，往往就是卡在 START TRANSACTION WITH CONSISTENT SNAPSHOT 等待上。

更实际的问题是：导出文件巨大（比如 2.4G 的 sbtest 库），传输慢、恢复时单线程导入耗时长，中间任一环节失败都得重来。

导出时没排除 mysql/sys 等系统库 → 导出直接失败
误包含自建日志库（如 error_log）→ 磁盘写满中断
用 mysql -e "source xxx.sql" 导入 → 没有进度反馈、无法断点续传

util.dumpInstance 必须设置的关键参数

它默认行为已经比较友好，但生产环境必须显式控制三件事：

用 excludeSchemas: ["mysql", "sys", "information_schema"] —— 不加这个，导出必然报错
用 consistency: "snapshot"（默认值）—— 依赖 MVCC，不触发 FLUSH TABLES WITH READ LOCK；若源库有 DDL 正在执行，需先 SHOW PROCESSLIST 杀掉或等它完成
outputUrl 必须指向 MySQL Shell 进程本地可写路径，例如 '/backup/mysql-dump-20260603/'，不能是数据库服务器上的路径，也不能是 /var/lib/mysql/ 下的子目录（SELinux 会拒写）

完整调用示例（在 MySQL Shell 内执行）：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

util.dumpInstance('/backup/mysql-dump-20260603/', {
  excludeSchemas: ["mysql", "sys", "information_schema"],
  consistency: "snapshot",
  bytesPerChunk: "128M",
  threads: 8
});

导入阶段不能只靠 mysql 命令

mysql -u root -p 对大文件极不友好：无并发、无压缩感知、失败后无法 resume。生产环境应改用 <code>util.loadDump，它天然支持并行、自动识别分片、跳过已存在对象、还能校验 checksum：

目标实例必须已启用 local_infile=ON（否则 LOAD DATA LOCAL INFILE 类语句会失败）
导入前确认 secure_file_priv 值为空或包含 dump 路径所在目录，否则报错 ERROR 1148 (42000): The used command is not allowed with this MySQL version
导入命令在 MySQL Shell 中执行：util.loadDump('/backup/mysql-dump-20260603/', {includeSchemas: ["order_db_0", "order_db_1"]})

注意：如果迁移涉及分库扩容（如从 uid % 2 到 uid % 4），util.dumpInstance 只负责全量克隆，路由逻辑适配仍需你用 Shell 脚本 + 条件查询做二次分发——它不改数据内容，只保结构和原始数据。