util.dumpinstance不会全程锁表，仅在create/drop database阶段短暂加全局读锁（毫秒级），默认启用一致性快照；显式设{consistency: "locked"}才全程ftwrl。
util.dumpInstance 会直接锁表吗？
不会全程锁表，但会在每个 schema 的 CREATE DATABASE 和 DROP DATABASE 阶段短暂加全局读锁（FLUSH TABLES WITH READ LOCK），时长通常在毫秒级。前提是源实例开启了 binlog 且未启用 --consistent（默认开启）。如果显式传入 {consistency: "snapshot"}，则依赖 START TRANSACTION WITH CONSISTENT SNAPSHOT，不触发 FTWRL，但要求引擎支持 MVCC（如 InnoDB）且不能有活跃的 DDL。
- 若源库有长事务或大 DDL 正在执行，
dumpInstance可能卡在获取一致性快照阶段 - 使用
{consistency: "locked"}才会强制全程 FTWRL，等同于传统 mysqldump --lock-all-tables - 建议克隆前检查
SHOW PROCESSLIST，避免在业务高峰执行
导出文件路径和权限要注意什么？
util.dumpInstance() 的 outputUrl 参数必须指向 MySQL Shell 进程本地可写路径，不是数据库服务器上的路径。Shell 默认以当前用户身份运行，所以该路径需满足：
- 目录存在且有写权限（常见坑：
/backup不存在或属主为 root） - 不要使用 MySQL 数据目录下的子路径（如
/var/lib/mysql/dump/），可能触发 SELinux 或 AppArmor 拒绝 - 路径中含空格或特殊字符时，必须用单引号包裹，例如：'
/mnt/nas/backup 2024/' - 如果用 NFS 或 CIFS 挂载点，确认已启用
noac或soft选项，否则小文件写入可能因缓存延迟失败
如何跳过特定 schema 或表？
util.dumpInstance() 不支持直接 exclude 列表，但可通过 excludeSchemas 和 includeSchemas 控制库级粒度：
-
excludeSchemas: ["mysql", "sys", "information_schema"]—— 必须显式排除系统库，否则导出失败（mysqldump兼容模式下也如此） - 无法按表过滤；若只需某几个表，应改用
util.dumpSchemas()或util.dumpTables() - 若误包含大日志库（如
error_log自建库），导出可能耗尽磁盘空间，建议提前SELECT COUNT(*)评估体积
目标实例恢复时为什么报错 “Unknown database”？
因为 util.dumpInstance() 导出的是“裸数据”，不含 CREATE DATABASE 语句（除非指定 {ddlOnly: false} 且源库存在）。恢复时需手动创建库，或改用配套工具：
- 直接用
mysqlsh --uri root@target:3306 --sql -e "CREATE DATABASE IF NOT EXISTS xxx"预建 - 更稳妥的方式是搭配
util.loadDump()使用，它会自动解析@.json元数据并建库 - 若跳过元数据文件（如删了
@.json），loadDump将无法还原 schema 结构，只剩表数据
实际迁移中，最易被忽略的是 outputUrl 的上下文归属——它永远属于客户端机器，不是数据库服务器。很多人把路径写成远程路径或相对路径，结果 dump 文件根本没生成，还以为命令静默失败。
