mysqldump迁移大库（>50GB或超千万行）默认极慢，调参无法根本解决，必须换mydumper或mysqlpump；若坚持用mysqldump，导出须加--single-transaction、--quick、--extended-insert、--skip-triggers、--skip-routines，导入前须执行SET FOREIGN_KEY_CHECKS=0、UNIQUE_CHECKS=0、autocommit=0。
直接说结论：mysqldump 迁移大库（单库 >50GB 或总行数超千万）默认就是慢的，不是调参能救回来的，必须改用 mydumper 或 mysqlpump；如果硬要用 mysqldump，必须同时满足导出和导入两端的参数组合，漏一个就卡在 1/10 速度。
mysqldump 导出时哪些参数必须加？
默认行为全是为小库设计的，对大库就是反模式：
-
--single-transaction：InnoDB 表必需，否则会锁全表；但和--lock-tables冲突，不能共存 -
--quick：强制逐行读取，防止大表数据全加载进内存导致 OOM；不加它，mysqldump会先把整张表 SELECT 结果缓存在客户端内存里 -
--extended-insert：生成多值 INSERT，比如INSERT INTO t VALUES (1),(2),(3);；不加它，默认是单行 INSERT，100 万行 = 100 万条语句，SQL 解析开销爆炸 -
--skip-triggers --skip-routines --skip-events：除非你真要迁移这些对象，否则跳过能减少 15%～30% 导出时间，还能避免权限或兼容性问题 -
--net_buffer_length=1048576：增大网络缓冲区，配合--extended-insert减少 TCP 包往返次数；默认 1MB 太小，尤其在千兆以上网卡上明显拖慢
错误示例：mysqldump -u root db > dump.sql —— 这种写法在百万行以上就会明显变慢；正确写法至少含前四项。
导入 SQL 文件为什么比导出还慢？
因为 mysql 客户端默认每条 INSERT 都做三件事：校验唯一索引、检查外键、自动提交事务。这三项加起来能让导入速度跌到原始吞吐的 1/10 以下。
- 导入前必须手动执行：
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0; SET autocommit=0; - 导入完再执行：
SET FOREIGN_KEY_CHECKS=1; SET UNIQUE_CHECKS=1;，并手动COMMIT; -
sql_log_bin=0可选，但要注意主从同步会跳过这批数据，需后续补位 - 别信
DROP TABLE IF EXISTS后面的DISABLE KEYS—— 它只对 MyISAM 有效，InnoDB 下完全无效
图形工具如 Navicat / Workbench 导入大文件时还会额外做语法高亮、进度渲染、连接保活，全是负优化，直接 kill 进程或 OOM 是常态。
为什么拆分 SQL 文件不一定提速？
拆分本身不提升吞吐，只解决两个实际问题：
- 导入中途失败后重试成本低：比如
split -l 50000 dump.sql拆成多个小文件，失败时只需重跑最后那个文件 - 绕过
max_allowed_packet限制：如果目标库设了 64MB，而导出的单条 INSERT 超过该值，会报错Packets larger than max_allowed_packet are not allowed
但注意：--where 分批导出（如 --where="id BETWEEN 1000000 AND 2000000"）比文本拆分更可控，前提是表有单调递增主键且无并发写入；否则空洞或重复数据风险很高。
真正适合大库迁移的替代方案
mysqldump 的天花板很明确：单线程、串行构造 SQL、无法跳过解析瓶颈。当库超过 100GB 或停机窗口小于 2 小时，就得换工具：
-
mydumper+myloader：最成熟，支持按表并行 + 大表分片（-t参数），实测比mysqldump快 3–10 倍；但要求源库有 LOCK TABLES 权限，且 GTID 环境下得加--no-locks --no-binlog -
mysqlpump：MySQL 5.7.8+ 自带，多线程默认开启，但不支持--where条件导出，想导部分数据得先建临时表 - 物理拷贝（
cp ibd）或 XtraBackup：快，但限制苛刻——版本一致、innodb_file_per_table=ON、无虚拟列/全文索引等；一旦漏查，ALTER TABLE ... IMPORT TABLESPACE直接报错
最容易被忽略的是字符集和 SQL mode 不一致：比如源库是 utf8mb4_0900_as_cs，目标库是 utf8mb4_general_ci，导入后中文乱码或排序异常，这种问题不会报错，但业务逻辑会悄悄出错。
