util.dumpInstance在TB级场景易卡住，因默认consistency: "snapshot"依赖一致性快照，需等待长事务和DDL完成；outputUrl须为Shell进程本地路径且有写权限；必须excludeSchemas排除系统库及日志库；loadDump依赖local_infile=ON且需手动启用--local-infile=1。
能，但必须绕开默认行为里的几个关键陷阱，否则 dumpInstance 会卡住、锁死或导出失败。
为什么 util.dumpInstance 在 TB 级场景下容易卡住
它不是“不锁”，而是“锁得聪明但有前提”：默认 {consistency: "snapshot"} 依赖 START TRANSACTION WITH CONSISTENT SNAPSHOT，这要求源库所有活跃事务都完成，且不能有正在执行的 DDL。TB 级实例上常见长事务（如未提交的归档任务）、大表 ALTER 或慢查询堆积，dumpInstance 就会一直等在“获取快照”这一步，看起来像卡死。
- 用
SHOW PROCESSLIST查看是否有State为Waiting for table metadata lock或长时间executing的线程 - 检查
information_schema.INNODB_TRX，确认TRX_STARTED时间过久的事务 - 避免在业务高峰或凌晨批处理时段启动 dump
outputUrl 必须是 Shell 进程本地路径，不是数据库服务器路径
这是最常踩的坑——误以为写 /var/lib/mysql/dump/ 是往数据库机器上存，其实 MySQL Shell 是个客户端程序，outputUrl 指向的是你运行 mysqlsh 命令那台机器的文件系统。如果 Shell 装在跳板机上，而你没在跳板机挂载足够空间的盘，dump 直接失败。
- 路径必须存在且当前用户有写权限：
mkdir -p /backup/mysql-$(date +%Y%m%d) && chown $USER:$USER /backup/mysql-$(date +%Y%m%d) - 禁用 MySQL 数据目录子路径，SELinux 或 AppArmor 会拦截写入
- NFS 挂载点要加
noac（禁用属性缓存），否则小文件写入可能因元数据延迟失败 - 含空格路径必须用单引号：
'/mnt/backup drive/tb-migration-202606/'
如何安全跳过系统库和日志库，防止导出失败或磁盘爆满
util.dumpInstance 不支持按表排除，只支持库级 excludeSchemas。不显式排除系统库会直接报错；不排查业务侧自建的日志库（如 audit_log、error_log）则可能把几十 GB 的日志表全扫进去，占满磁盘。
- 必须传：
excludeSchemas: ["mysql", "sys", "information_schema", "performance_schema"] - 提前查一遍有哪些非业务库：
SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql','sys','information_schema','performance_schema') AND SCHEMA_NAME NOT LIKE 'test%'; - 对疑似日志库，进库看最大表：
SELECT TABLE_NAME, ROUND((DATA_LENGTH+INDEX_LENGTH)/1024/1024,2) size_mb FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'xxx' ORDER BY size_mb DESC LIMIT 3; - 若只需迁移部分库，改用
util.dumpSchemas()更可控
恢复时 util.loadDump 的速度优势和隐含依赖
它比 mysqldump 导入快的核心原因是用 LOAD DATA LOCAL INFILE，不是拼 INSERT。但这要求目标 MySQL 实例开启 local_infile=ON，且客户端连接时带 --local-infile=1 参数——Shell 默认不带，得手动加。
- 目标库检查：
SELECT @@local_infile;，若为OFF，需在 my.cnf 加local_infile=ON并重启 - Shell 连接目标库时显式启用：
mysqlsh --local-infile=1 -u root -h target-host - 导入前确保目标磁盘有足够空间，
LOAD DATA不走 buffer pool，是直写磁盘文件 - 不要在恢复中途 Ctrl+C，已导入的分片不会自动回滚，后续重试可能主键冲突
真正决定 TB 级迁移成败的，从来不是工具本身多快，而是你有没有在 dump 前 kill 掉那个跑了 6 小时还没提交的事务，以及有没有确认 Shell 进程所在机器的 /backup 目录是不是真的挂了 10TB 的盘。
