MySQL Shell dump比mysqldump快，因其默认多线程并行导出、直接读取存储引擎数据页，跳过SQL解析拼装；实测100GB数据，前者45分钟，后者4小时+，关键需MySQL Shell≥8.0.21且binlog_row_image=FULL。
MySQL Shell dump 为什么比 mysqldump 快？
因为 mysqldump 是单线程、基于 SQL 文本导出，而 util.dumpInstance() 或 util.dumpSchemas() 默认启用并行导出（多线程读取表、多文件写入），且直接读取存储引擎数据页（InnoDB）或表元数据，跳过 SQL 解析与拼装开销。实测 100GB 数据，mysqldump 耗时 4h+，util.dumpInstance() 在 8 核机器上约 45 分钟完成。
关键前提是：源库必须开启 binlog_row_image=FULL（默认满足），且 MySQL Shell 版本 ≥ 8.0.21（推荐用 8.0.33+），否则并行导出可能降级为串行。
怎么调用 dump 并控制并行度？
核心是传参 threads 和 chunking，不是越多线程越快——它受磁盘 I/O、CPU 和源库负载共同制约。常见误配是设 threads: 32 导致源库连接数爆满或 IO 堵塞。
-
threads：建议设为 CPU 核数 × 1.5（如 8 核 →threads: 12），超过 16 很少带来收益 -
chunking: true（默认开启）：大表自动按主键分片导出，避免单个线程卡死；若表无主键，会退化为全表扫描，此时应手动加bytesPerChunk -
bytesPerChunk：对无主键或主键不均匀的表，设bytesPerChunk: 128*1024*1024（128MB）更稳 -
excludeSchemas：排除sys、performance_schema等系统库，避免权限报错
示例命令：
util.dumpInstance("/backup/full", {
threads: 12,
excludeSchemas: ["mysql", "sys", "information_schema"],
showProgress: true
})
restore 时为什么卡在 “Loading DDL” 阶段？
这是最常见的阻塞点：MySQL Shell 的 util.loadDump() 默认先集中执行所有 DDL（建库、建表），再批量导入数据。如果目标实例 innodb_buffer_pool_size 过小或并发连接数不足，DDL 执行慢，后续数据线程全在等。
解决办法是拆开流程：
- 先用
util.loadDump()加loadDDLSFirst: false参数，让 DDL 和数据导入交错进行 - 确保目标库
innodb_buffer_pool_size ≥ 50% 可用内存，且max_connections ≥ threads × 2 - 禁用唯一性检查加速导入：
session.runSql("SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;")再调util.loadDump()
注意：loadDDLSFirst: false 要求 dump 文件里每个表的 DDL 和数据文件都在同一目录下（默认结构满足），否则会报 Missing DDL file for table 错误。
跨版本迁移时哪些参数必须检查？
MySQL 5.7 → 8.0 或 8.0.x → 8.0.y 迁移，dump 本身兼容，但恢复失败常因隐式行为变化：
- 8.0 默认
sql_mode含STRICT_TRANS_TABLES，若 dump 中有非法日期（如 '0000-00-00'），loadDump()直接报错；可在 restore 前临时设sql_mode='' - 字符集差异：若源库用
utf8mb4_0900_as_cs而目标库未安装该 collation，需提前执行INSTALL COMPONENT "file://component_validate_password"（实际是装 collation，但 MySQL 没单独命令，得靠升级或初始化时带） -
dataDir权限问题：dump 生成的@.json文件里记录了绝对路径，若目标机路径不同，loadDump()会尝试访问原路径——必须用os.path工具重写或指定compatibility参数
最稳妥做法：迁移前在目标环境用 mysqlsh --sql -e "SELECT VERSION(), @@sql_mode, @@collation_server;" 对比确认。
