myloader本身不加速导入，真正提速依赖mydumper分片备份、线程数匹配硬件及目标库调优；-t参数无效主因是并发粒度为文件而非行/表，若备份未分块则无法并行，且myisam不支持并发写入、外键/唯一索引未关闭、缓冲池未调优均会导致线程空闲或卡顿。
myloader 本身不加速导入，它只是把 mydumper 的多线程备份文件“按设计方式”还原；真正提速的关键是：备份时是否分片、线程数是否匹配硬件、目标库是否已调优。
myloader -t 参数为什么经常没效果？
常见现象是执行 myloader -t 8 后，SHOW PROCESSLIST 只看到 1–2 个活跃的 INSERT 线程，其余线程空闲或卡在锁等待。
- 根本原因：myloader 的并发粒度是「文件」，不是「行」或「表」——如果 mydumper 备份时没分块（比如没用
-F或-r），那每张表就只有 1 个.sql文件，-t 8实际只能并行处理 8 张不同的表 - MyISAM 表默认不支持并发写入，即使开了多线程也退化为串行；InnoDB 表才真正受益于多线程导入
- 目标库若启用了外键约束或唯一索引，
myloader会逐条插入并校验，无法批量 bypass —— 必须提前执行SET FOREIGN_KEY_CHECKS=0和SET UNIQUE_CHECKS=0
导入前必须做的三件事
不做这些，开再多线程也白搭，甚至更慢。
- 关闭约束：
mysql -e "SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;"（导入完成后记得恢复） - 禁用自动提交：
mysql -e "SET autocommit=0;"，让 myloader 的事务批量生效（它默认每 1000 行提交一次，但受制于表结构） - 确认
innodb_buffer_pool_size已设为物理内存的 50%–70%，否则大量数据页频繁换入换出，IO 拉垮整体速度
myloader 线程数和分片策略怎么配？
线程数不是越多越好，它受限于磁盘 IO、MySQL 连接数上限和单表文件数量。
- 先查可用连接数：
SELECT @@max_connections;，myloader -t N会占用 N 个连接，别超限 - SSD 环境下，
-t建议设为 CPU 物理核心数 × 1.2（如 16 核配-t 19），超过 24 后收益下降明显 - 大表必须分片：mydumper 备份时加
-r 500000（按行）或-F 100（按 MB），否则 myloader 拿不到足够多的小文件来并发 - 避免单文件 >2GB：加
--chunk-filesize 50，防止 OOM 或网络传输中断（尤其走 rsync 或对象存储时）
容易被忽略的兼容性坑
myloader 不会帮你处理环境差异，很多失败源于隐式假设。
- 备份时若含
TIMEZONE相关字段，不加--skip-tz-utc会导致每条INSERT都带CONVERT_TZ()，性能掉 20%+ - metadata 记录的是备份开始时刻的 binlog pos，不是结束时刻 —— 若备份耗时 >5 分钟，PITR 恢复时得手动校准
SHOW MASTER STATUS - myloader 不自动关外键，也不重建索引；导入后务必手动
ALTER TABLE ... ENABLE KEYS;（如果备份前删了索引）
