如何利用MySQL Shell的util.dumpInstance实现TB级数据快速迁移？-mysql教程-PHP中文网

util.dumpinstance在tb级场景易卡住，因默认consistency: "snapshot"依赖一致性快照，需等待长事务和ddl完成；outputurl须为shell进程本地路径且有写权限；必须excludeschemas排除系统库及日志库；loaddump依赖local_infile=on且需手动启用--local-infile=1。

如何利用mysql shell的util.dumpinstance实现tb级数据快速迁移？

能，但必须绕开默认行为里的几个关键陷阱，否则 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 直接失败。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

路径必须存在且当前用户有写权限：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() 更可控