mydumper/myloader可将百GB级MySQL全量迁移压缩至1.5–2.5小时内，但须规避四大陷阱：非InnoDB表需先转为InnoDB、提前建库建表、设置max_allowed_packet≥256M、必加--skip-tz-utc防datetime偏移。
mydumper 和 myloader 能把百GB级 MySQL 全量迁移从“等一整晚”压缩到几小时内，但前提是避开几个关键陷阱——线程数乱设、表结构不提前建、非 InnoDB 表没处理、字符集或时区参数漏掉。
导出前必须确认的三件事
百GB数据不是靠堆线程就能快起来的，第一步是排除底层阻碍：
-
mydumper的一致性快照依赖START TRANSACTION WITH CONSISTENT SNAPSHOT，只对InnoDB表生效；用SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND engine != 'InnoDB'检查，有MyISAM表必须先转：ALTER TABLE t ENGINE=InnoDB - 源库
max_allowed_packet至少设为256M，否则大 BLOB 字段会截断，报错类似MySQL server has gone away - 务必加
--skip-tz-utc，否则DATETIME字段在跨时区导入时可能偏移 1 小时（尤其源库在 UTC+8，目标在 UTC）
mydumper 导出时线程与分块怎么配
线程数不是越多越好，实测 8 核机器上 -t 12 是甜点值；超过 16 后磁盘 IO 和连接争抢反而拖慢整体速度：
- 大表（>500 万行）用
--rows 1000000拆块，避免单文件过大导致内存溢出或导入卡顿 - 小表（--rows，否则生成一堆碎片文件，
myloader启动时元数据扫描开销剧增 - 加
--compress可减小传输体积，但导出耗时增加约 15%～20%，如果本地 SSD 快、网络带宽高，可考虑关掉 - 避免
--regex匹配全库，改用-B db_name -T table1,table2,...显式指定，减少元数据遍历时间
myloader 导入失败最常见的三个原因
myloader 不建库、不建表、不处理外键约束——它只执行 INSERT。报 Table doesn't exist 或死锁，基本都栽在这三点：
- 导入前必须手动建库：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS target_db" - 必须先恢复 schema：
cat ./backup_dir/metadata | grep "CREATE TABLE" | mysql -u root -p target_db（或用mydumper --no-data -B db_name -o schema_only单独导出） - 目标库已有数据且含外键时，导入前执行
SET FOREIGN_KEY_CHECKS=0；导入完成再SET FOREIGN_KEY_CHECKS=1校验 - 漏掉
-d ./backup_dir参数会导致myloader找不到schema和data子目录，直接报路径错误
跨环境迁移时容易被忽略的兼容性点
从本地 MySQL 迁到云数据库（如 Azure DB for MySQL、OceanBase MySQL 模式）时，行为差异更隐蔽：
- 云服务常默认关闭
local_infile，而myloader在某些版本中会尝试用LOAD DATA INFILE加速，需加--use-compress或确认目标库已开local_infile=ON - OceanBase 等兼容层对
DEFINER语句敏感，导出时加--no-definer避免导入失败 - 字符集若混用
utf8mb4_0900_as_cs（MySQL 8.0 默认）和旧版utf8mb4_general_ci，建表语句会报错，建议统一用utf8mb4_unicode_ci - 目标库若为只读实例或有 binlog 限流策略，导入时加
-e（启用 binlog）可能导致延迟飙升，生产环境建议关掉-e，后续靠主从同步补数据
MyISAM 表、导入前忘了跑一遍 CREATE DATABASE、或者时区参数 --skip-tz-utc 漏了——这些地方一错，后面所有线程优化都白搭。 
