导出前必须关闭autocommit并禁用锁表：用--skip-add-locks和--single-transaction避免锁表，导入端设autocommit=0等提升性能；分库分表分阶段导出，先处理大表再批量导小表，结构单独导出；压缩传输改用split切片+gzip+rsync断点续传。
导出前必须关掉 autocommit 和锁表行为
默认 mysqldump 会在每个表前加 LOCK TABLES，上百个表意味着上百次锁表+解锁，不仅慢，还可能被其他写入阻塞甚至超时失败。更关键的是，它默认开启 autocommit=1，导致每条 INSERT 都提交一次，I/O 压力爆炸。
实操建议：
- 用 --skip-add-locks 禁用显式锁表
- 加 --single-transaction（仅 InnoDB）保证一致性且不锁表
- 导入端配合 SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;，否则导入时每条 INSERT 都校验约束
- 导出时不带 --add-drop-table（除非你确定目标库完全干净），避免重复建表失败
导出命令要分库、分表、分阶段处理
上百个表的单库，直接 mysqldump -u root -p mydb > full.sql 容易因内存不足或超时中断，尤其当有大 BLOB/TEXT 字段时。不分阶段的全量导出也难定位失败点。
推荐做法：
- 先用 mysql -Nse "SELECT table_name FROM information_schema.tables WHERE table_schema='mydb' ORDER BY data_length DESC" 拿到按大小排序的表名列表
- 把最大的前 5–10 个表单独导出： mysqldump -u root -p --no-create-info --skip-triggers mydb big_table1 > big_table1.sql
- 其余表用循环批量导出（避免一次性加载太多表名进内存）：for t in $(mysql -Nse "SELECT table_name FROM information_schema.tables WHERE table_schema='mydb' AND data_length > small_tables.sql; done
- 表结构统一用 mysqldump -u root -p --no-data mydb > schema.sql 单独导出，确保字符集和引擎定义完整
压缩与传输必须绕过 shell 管道瓶颈
直接 mysqldump ... | gzip > dump.sql.gz 看似省事，但一旦中间某环节卡住（比如 ssh buffer 满、gzip 内存溢出），整个管道就断，且无法 resume。上百个表导出耗时长，网络波动极易导致重传成本高。
更稳的做法：
- 导出为原始 SQL 文件（不压缩），用 split -l 500000 dump.sql chunk_ 切片，每片约 50 万行
- 对每个 chunk 用 gzip 单独压缩，失败只影响单个分片
- 用 rsync --partial --progress 传到目标机，支持断点续传
- 导入时不要 mysql -u root -p （gunzip 会阻塞 stdin），而是先解压再导入：<code>zcat dump.sql.gz | mysql -u root -p mydb
导入时跳过日志刷盘和唯一性检查
默认配置下，InnoDB 每次事务都刷 redolog（innodb_flush_log_at_trx_commit=1）和 binlog（sync_binlog=1），对大批量 INSERT 是性能杀手。上百个表导入期间若保持这些设置，速度可能比导出还慢。
安全提速操作：
- 导入前在目标库执行：SET GLOBAL innodb_flush_log_at_trx_commit=2; SET GLOBAL sync_binlog=0;
- 导入完成后立即恢复：SET GLOBAL innodb_flush_log_at_trx_commit=1; SET GLOBAL sync_binlog=1;
- 如果目标库不需要 binlog（如测试环境），可启动时加 --skip-log-bin，彻底关闭
- 注意：这些调优只应在迁移窗口期内生效，不可长期保留
真正麻烦的不是命令怎么写，而是大表的主键重建、索引合并、以及外键依赖顺序——这些在 mysqldump 生成的 SQL 里是隐式发生的，出错时只报“Duplicate entry”或“Cannot add or update a child row”，得翻几百行 SQL 才能找到冲突源头。务必在导入前用 grep -n "INSERT INTO `table_name`" dump.sql 快速定位问题段落。
