MySQL Shell的dump和load比mysqldump快，因其默认并行导出+LOAD DATA导入（比INSERT快约20倍），支持自动分块、延迟建索引、zstd压缩，且需关闭performance_schema consumer以避免元数据查询拖慢20%~40%。
MySQL Shell 的 dump 和 load 为什么比 mysqldump 快
因为 MySQL Shell 的 util.dumpInstance() 和 util.loadDump() 默认走的是并行导出 + LOAD DATA LOCAL INFILE 导入路径，而不是逐条 INSERT。官方实测 LOAD DATA 比批量 INSERT 快约 20 倍；同时它自动分块、延迟建索引、内置 zstd 压缩，这些都不是 mysqldump 原生支持的。
必须关闭 performance_schema 才能发挥 Shell 备份速度优势
MySQL 8.0 默认开启所有 performance_schema consumer，而 Shell 的 dump 过程会触发大量元数据查询（比如表结构、列权限、统计信息），每次查询都经过 events_statements_history_long 等采集链路，实测拖慢 20%~40%。不关它，Shell 的并发优势会被抵消。
- 执行
UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME LIKE 'events_statements_%' OR NAME LIKE 'events_waits_%'; - 注意：不能用
SET GLOBAL，必须用UPDATE更新表；该操作仅对当前会话生效，备份完无需手动恢复 - 如果用
mysqlsh --js脚本调用 dump，需在连接后立即执行这条 SQL
dump 参数中哪些真正影响速度
Shell 的 dump 性能敏感参数不多，但几个关键项选错会导致线程闲置或 I/O 卡顿：
-
--threads：默认为 CPU 核数，但实际有效值受innodb_buffer_pool_size和磁盘随机读能力限制；建议从 4 开始测试，超过 8 很少再有收益 -
--chunking：默认开启，对大表自动切块；若关掉（--chunking=false），单线程扫全表，彻底失去并行意义 -
--compression=zstd：比 gzip 快且压缩率高，但需要客户端和服务器都支持 zstd（MySQL 8.0.19+）；若不支持会自动降级为 none，不报错但浪费带宽 -
--skipBinLog：避免 dump 过程写 binlog，减少主库日志压力；生产环境建议加上
load 时容易忽略的权限和配置陷阱
util.loadDump() 依赖 LOCAL INFILE，而它被很多环境默认禁用，一试就卡在 “Access denied” 或静默失败：
- 服务端必须开启
local_infile=ON（SET GLOBAL local_infile = ON;），且该变量不可动态禁用，重启后失效 - 客户端连接时要显式加
--local-infile=1参数，否则即使服务端开了也拒绝加载 - 目标库若启用了
sql_log_bin=OFF，load 过程不会记录 binlog，但若后续要做主从同步，需手动补 binlog 或跳过该段 - 遇到
ERROR: Failed to load table xxx: Invalid default value for 'xxx'，通常是目标库sql_mode比源库严格（如含STRICT_TRANS_TABLES），需提前统一
performance_schema consumer —— 很多人只调 --threads，却没意识到默认采集机制正在后台悄悄拖慢每一张表的元数据获取。 
