myloader不支持分表分库混合粒度并行恢复，仅支持单命令内通过-t参数控制线程级并发；分库需提前隔离备份目录并配合-s（源库白名单）和-b（目标库）参数；单表恢复须确保目录纯净且目标表不存在。
myloader 本身不支持“分表分库并行恢复”这种混合粒度操作——它按目录结构自动识别库/表，恢复时并发的是线程，不是你指定的“哪些库或哪些表先跑”。真正可控的并行，只发生在单次 myloader 命令内部。
myloader 的 -t 参数控制实际并发线程数
恢复速度主要取决于 -t（threads）参数值，而不是你手动拆分多少个命令。默认是 4 线程，设为 8 或 16 能显著提升吞吐，但要注意目标 MySQL 的 max_connections 和磁盘 IO 承载能力。
-
myloader -u u_mydumper -p Ud8agc_a -S /tmp/mysql.sock -d ./bak1/ -t 8：8 个线程并行导入所有表 - 线程数过高会导致连接池耗尽、锁等待加剧，反而拖慢整体进度
- 实测中，线程数设为 CPU 核心数 × 2 是较稳妥的起点（例如 8 核机器用
-t 16）
想“分库恢复”，必须用 -B 指定目标库名，且备份目录里不能混多个库
myloader 不会自动从备份目录里“挑出某个库来恢复”，它读取整个 -d 目录下的所有 .sql 文件，并按文件名前缀（如 bak1.t1-schema.sql）推断所属库表。所以：
- 如果备份时用了
-B bak1，那么./bak1/目录下只有bak1库的文件，此时加-B bak1_recover就能把全部表导入新库 - 如果备份目录里混了
bak1和bak2的文件（比如用-T bak1.t1,bak2.t3生成的），myloader会一并恢复——它不认“库边界”，只认文件名 - 要真正分库恢复，得提前把不同库的备份文件放到不同目录，再分别执行
myloader
单表恢复必须确保目标库干净，且不能依赖 myloader 的过滤能力
myloader 没有 --tables 这类参数，它不会跳过目录里你不想要的表。所谓“单表恢复”，实际是：
- 先确认备份目录
./bak1_t1/下只有bak1.t1相关的两个文件：bak1.t1-schema.sql和bak1.t1.sql - 目标库中不能存在同名表，否则报错
Table 't1' already exists；必须提前执行DROP TABLE IF EXISTS bak1_recover.t1 - 加
-o参数可覆盖已有表，但会清空数据——这在生产环境风险极高，慎用 - 若备份目录里还有其他表文件，哪怕你只想恢复 t1，
myloader也会全量导入
跨库恢复时 -s 和 -B 的组合容易混淆
这两个参数作用完全不同，但名字相近，极易配错：
-
-s db1：告诉myloader“源备份文件里标记为db1的表，才允许导入”，相当于白名单过滤（需备份时已按库组织好文件） -
-B db2：指定“所有导入的表都写进db2库”，不管源文件里原库名是什么 - 典型用法：
myloader -u ... -d ./full_backup/ -s bak1 -B bak1_recover表示：从 full_backup 目录中只取原属bak1的表，导入到bak1_recover库 - 若漏掉
-s，而目录里有几十个库的文件，myloader会全扫一遍，可能误建大量表
真正需要“分表分库并行”的场景，本质是调度问题，不是 myloader 能解决的——得靠外部脚本启动多个 myloader 进程，各自指向不同子目录，并协调好目标库名和连接资源。这时候，备份阶段的目录隔离和命名规范，比恢复时的参数更重要。
