threads参数合理值为cpu核数×1.5（如8核设12），超16基本无收益；源库max_connections须≥threads×2，否则报“too many connections”；无主键表chunking失效，需改用bytesperchunk按字节切片。
threads参数设多少才合理？
不是越多越快，8核机器设threads: 32反而容易拖垮源库。实际瓶颈常在磁盘I/O或连接数，而非CPU空闲。
-
threads建议设为CPU核数 × 1.5（如8核→threads: 12），超过16基本无收益 - 源库
max_connections必须≥threads × 2（每个线程可能占多个连接），否则导出中途报Too many connections - 目标库导入时
threads可略高（如32），但需同步调大innodb_buffer_pool_size和max_allowed_packet
chunking开启后为什么大表还是卡住？
因为chunking: true只对有主键的表生效——它按主键分片；无主键表会退化为全表扫描，单线程扛整张表，threads再多也无效。
- 检查表是否有主键：
SHOW CREATE TABLE t1，若PRIMARY KEY缺失，必须手动干预 - 对无主键表，加
bytesPerChunk: 128*1024*1024（128MB）强制按字节切片，避免OOM或超时 - 主键不均匀（如自增ID但存在大量删除）时，
bytesPerChunk比默认的行数切片更稳
excludeSchemas漏配会直接失败
util.dumpInstance()遇到mysql、sys等系统库会因权限不足或元数据冲突立即退出，不是跳过，是中断。
- 必须显式排除：
excludeSchemas: ["mysql","sys","information_schema","performance_schema"] - 业务侧日志库（如
audit_log、error_log）也要一并排除，否则可能把几十GB日志表全扫进去 - 用这条SQL查非系统库：
SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql','sys','information_schema','performance_schema') AND SCHEMA_NAME NOT LIKE 'test%'
outputUrl路径写错等于白跑
outputUrl指向的是运行mysqlsh命令那台机器的本地路径，不是数据库服务器路径。很多人误写/var/lib/mysql/dump/，结果dump进程在跳板机上找这个目录，直接报No such file or directory。
- 路径必须提前创建且用户有写权限：
mkdir -p /backup/mysql-$(date +%Y%m%d) && chown $USER:$USER /backup/mysql-$(date +%Y%m%d) - NFS挂载点要加
noac选项，否则小文件写入可能因元数据缓存延迟失败 - 含空格路径必须用单引号：
'/mnt/backup drive/tb-migration-202606/'
consistency: "snapshot"等待长事务释放MDL锁——这和并发数无关，得先KILL掉information_schema.INNODB_TRX里TRX_STARTED超30分钟的事务。
