MySQL Shell恢复大库前必须确认三件事：一是mysqlsh版本≥8.0.22，二是目标实例已启用local_infile=ON，三是SQL备份文件不含DROP DATABASE或跨库语句且结构合规。
mysqlsh 恢复大库前必须确认的三件事
MySQL Shell（mysqlsh）本身不直接替代 mysql 命令导入 SQL 文件，它不是“更快的 mysql -e”，而是面向开发和管理的交互式工具。想用它恢复大型数据库，先得明确：它只在特定场景下有优势——比如从 MySQL Enterprise Backup 或 Clone 插件导出的数据，或配合 util.importTable() 加载 CSV/JSON；对标准 mysqldump 生成的 SQL 文件，mysqlsh 并不加速，反而可能更慢。
实际操作前务必确认：
-
mysqlsh版本 ≥ 8.0.22（低版本不支持并行导入或大文件流式处理） - 目标实例已启用
local_infile=ON（否则util.importTable()会失败） - SQL 备份文件不含
DROP DATABASE或跨库语句（mysqlsh的util.loadDump()要求 dump 来自mysqldump --single-transaction --routines --triggers且结构清晰）
用 util.loadDump() 恢复 mysqldump 全量备份
这是最接近“快速恢复”的官方路径，但仅适用于由 mysqldump + --set-gtid-purged=OFF（或 GTID 已关闭）生成的备份，且需提前用 mysqldump 的配套工具 mysqlpump 或 mysqldump 自带的 --skip-triggers --skip-routines 等做预处理。
实操步骤：
- 先创建空库：
mysqlsh -u root -p -e "CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" - 确保备份目录结构合规：dump 必须是
mydb/子目录下含@.sql和表文件，不能是单个mydb.sql - 执行导入：
mysqlsh -u root -p --sql -e "util.loadDump('/path/to/dump_dir', {schema: 'mydb', loadUsers: false, skipBinLog: true});" - 关键参数说明：
skipBinLog: true防止恢复过程写 binlog（避免主从冲突），loadUsers: false避免覆盖权限表（除非你明确要还原用户）
注意：util.loadDump() 默认并发线程数为 4，大表恢复时可加 threads: 8 提升吞吐，但会显著增加内存和磁盘 I/O 压力。
大表恢复卡住？优先切到 mysql 命令 + 参数调优
当 util.loadDump() 在导入百万行以上单表时频繁超时或 OOM，别硬扛——mysqlsh 对纯 SQL 导入并无底层优化，此时退回传统 mysql 命令反而更稳、更快。
推荐组合命令（针对 1GB+ dump 文件）：
mysql -u root -p --default-character-set=utf8mb4 \ --max-allowed-packet=1G \ --net-buffer-length=1M \ -e "SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;" \ mydb < /backup/mydb.sql
关键点：
-
--max-allowed-packet=1G必须 ≥ dump 中最长一行（否则报Packets larger than max_allowed_packet） -
SET unique_checks=0关闭唯一索引校验，导入速度提升 3–5 倍，但结束后务必手动ANALYZE TABLE - 不要用
source在交互式 mysql 客户端里执行大文件——它会把整个文件读入内存再解析
真正适合大库的“快速恢复”其实是物理备份
如果你追求的是 TB 级数据分钟级恢复，mysqlsh 不是答案。mysqlsh 的 util.cloneInstance() 或配合 Percona XtraBackup 的 util.loadDump() 才是正解，但这要求你事先用 xtrabackup 做过物理备份。
例如，已有 XtraBackup 全量备份：
- 停库、清空
/var/lib/mysql、xtrabackup --copy-back - 启动后，在
mysqlsh里只需运行：util.checkInstanceConfiguration()和dba.configureLocalInstance()校验配置即可 - 整个过程耗时取决于磁盘拷贝速度，与 SQL 解析无关
真正容易被忽略的是：所有所谓“快速恢复”都建立在备份类型匹配的前提下——逻辑备份再快也快不过文件拷贝，而 mysqlsh 只是工具链中的一环，不是性能银弹。
