myloader比mysql source快是因为其多线程并行导入机制：主线程仅负责建库建表及元数据，多个worker线程各自独立加载.sql文件，实现按文件级并行，而source是单线程顺序执行SQL。
myloader 为什么比 mysql source 快？
因为 mysql 命令行工具是单线程顺序执行 SQL，遇到大文件（比如几 GB 的 test.sbtest1.sql）会卡住很久；而 myloader 启动多个工作线程，每个线程独立加载一个 .sql 文件，真正实现「按文件并行」。主线程只负责建库建表、最后补函数/视图/触发器，不参与数据行插入。
导入前必须确认的三件事
缺一不可，否则导入中途失败或数据不一致：
-
myloader备份目录结构必须完整：至少包含metadata、database.table-schema.sql、database.table.sql，少任何一个文件都会报错ERROR: No schema file found for table... - 目标库字符集要和源库一致 ——
myloader不处理字符集转换，若源库是utf8mb4而目标库是latin1，中文字段直接乱码 - 目标 MySQL 实例必须已启用
innodb_file_per_table=ON，否则大表导入时可能因共享表空间不足而中断
myloader 关键参数怎么选？
不是线程越多越好，得看硬件和数据分布：
-
-t 8是常见起点：8 核 CPU 可以跑满，再高容易触发Too many connections或磁盘 IO 瓶颈 -
--queries-per-transaction 5000比默认 1000 更稳：减少事务提交频率，降低 binlog 写入压力，尤其在开启-e时 -
-o（覆盖表）慎用：它会先DROP TABLE，如果目标库有外键依赖或正在被应用读取，会立刻报错ERROR 1217 (HY000): Cannot delete or update a parent row - 跨库恢复用
-B newdb -s olddb，别漏掉-s，否则myloader默认从备份目录里找所有库，不是只导olddb
导入后最容易被忽略的验证点
很多人跑完 myloader 就以为完事了，但以下两处常出问题：
-
metadata里的Finished dump at:时间戳，要和你期望的备份一致性时间对齐；如果导入的是旧备份，但业务还在写新数据，这个时间就是唯一可信的快照锚点 - 触发器、事件、存储过程是否真的生效？
myloader最后阶段才执行这些对象，如果中途被 kill 或磁盘满，它们不会回滚 —— 需手动检查SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'your_db';
