MySQL 8.0.21+ 应使用 util.dumpInstance 和 util.loadDump 替代 mysqldump，因其支持并行、压缩、分块及 LOAD DATA 高速导入；mysqldump 单线程、无压缩、不支持分块，并发与性能差，8.0 后已不推荐。
util.dumpInstance 和 util.loadDump 是 MySQL 8.0.21+ 官方推荐的替代方案，比 mysqldump 快得多，且默认支持并行、压缩、分块和 LOAD DATA 导入——不是靠拼 INSERT，而是直接走底层高速通道。
为什么 mysqldump 在 8.0 后不该再用
它本质是单线程生成 INSERT 语句，恢复时重放 SQL，IO 和解析开销大；官方文档明确指出 LOAD DATA 比 INSERT 快约 20 倍。而 mysqldump 不支持分块、无原生压缩、无法并行导入，备份 10GB 表可能要 30 分钟，恢复更久。MySQL 8.0.34 起 mysqlpump 已被标记为 deprecated，mydumper 则非官方，维护和兼容性风险高。
util.dumpInstance 备份整个实例时的关键参数
执行前确保目标目录为空，且用户有 BACKUP_ADMIN 或 RELOAD + SELECT 权限（尤其需要一致性快照时）：
-
threads: 默认 4，建议设为 CPU 核数的 70%～80%，比如 16 核机器可设{threads: 12}；设太高反而因锁竞争拖慢 -
compression: 默认"zstd"，比"gzip"压缩率更高、解压更快；若目标环境没 zstd 库，才降级用"gzip" -
bytesPerChunk: 默认"64M"，小表自动合并为一个文件；大表会被切片，每片独立线程处理——这是并行提速关键 -
excludeSchemas: 如需跳过sys、performance_schema，显式传["sys", "performance_schema"]，别依赖默认行为 -
consistent: 默认true，会触发FLUSH TABLES WITH READ LOCK+START TRANSACTION WITH CONSISTENT SNAPSHOT；若只读从库或能接受最终一致性，可关掉省锁等待
util.loadDump 恢复时最容易踩的坑
不是把文件丢进去就完事——权限、路径、字符集、用户定义都可能中断导入：
- 必须用同一版本或更高版的
mysqlsh执行util.loadDump，低版本无法识别新格式元数据（如@.done.json中的 GTID 信息） -
loadUsers默认false，要迁移账号得显式加{loadUsers: true}；但注意目标实例必须允许写mysql.user表，否则报ERROR 1227 (42501) - 备份中含
DEFINER的视图/函数，若目标无对应用户，会卡在CREATE ALGORITHM=行；提前加--skip-definer不适用——util.dump*没这参数，只能用postProcess脚本改 JSON 元数据或删@.users.sql - 导入路径必须是绝对路径，且
mysqlsh进程有读权限；Windows 下路径写成"C:\backup\mydump"，Linux 下用"/backup/mydump"，别漏斜杠 - 不支持管道导入：
util.loadDump只认本地目录结构，不能接cat dump.tgz | gunzip | ...
备份目录结构决定你能否做增量或复制搭建
util.dumpInstance 输出不是扁平 SQL 文件，而是一套带元数据的结构化目录。其中 @.json 记录了 binlogFile 和 binlogPosition，@.done.json 包含 gtidExecuted ——这意味着你可以直接用这个备份点搭从库，不用再手动查位点。但前提是源库开了 binlog 且引擎是 InnoDB；如果备份时没触发一致性锁（比如 consistent: false），这些位置信息就不可靠。
