MySQL 大数据库分卷导出与导入完整指南：使用 mysqldump --skip-extended-insert 与 split 命令
如何利用 mysqldump 配合 split 命令分卷导出大型 SQL 文件
当您需要备份或迁移超过 2GB 的 MySQL 数据库时，直接导出单个 SQL 文件常会遇到“文件过大”或传输中断的问题。由于 mysqldump 工具本身不支持分卷，我们可以借助 Linux/Unix Shell 的管道功能，将 mysqldump 与 split 命令结合使用，实现安全高效的分卷备份。
分卷的核心难点并非简单的文件切割，而是必须保证每个分割文件的 SQL 语法完整性。如果切割点恰好位于一条 SQL 语句中间，在后续导入时必然会导致语法错误（如 ERROR 1064 (42000)），使得数据恢复失败。
- 首先，在导出命令中必须加入
--skip-extended-insert参数。此参数的作用是让每条INSERT数据记录独立成行，避免生成超长的单行INSERT语句，从而从根本上防止split命令将一条完整的 SQL 语句切分成两半。 - 推荐使用
split -b 500M -d --additional-suffix=.sql进行切割。-b参数按固定字节大小分割，最为可靠；-d参数使用数字后缀（如 00, 01），便于排序；--additional-suffix参数直接为生成的文件添加.sql扩展名，管理更直观。 - 切勿使用
split -l按行数切割。SQL 文件中包含的注释、空行以及多行语句结构会使行数切割法完全失效，产生无法导入的碎片化文件。 - 完整的导出命令示例如下：
mysqldump -u root -p --skip-extended-insert mydb | split -b 500M -d --additional-suffix=.sql - dump_
执行后，将生成一系列文件，例如dump_00.sql、dump_01.sql等。
导入分卷 SQL 文件的关键步骤：必须按顺序合并后执行
分卷文件并非独立的数据库脚本。例如，dump_00.sql 的末尾可能是一条未写完的 INSERT 语句，或一个未提交的事务。如果尝试单独导入每个文件（如 mysql -u root -p mydb < dump_00.sql），极有可能遇到连接中断错误（ERROR 2013），导致导入过程失败。
唯一正确的方法是将所有分卷文件按照命名顺序拼接成一个完整的 SQL 流，再一次性导入到目标数据库中。
- 在 Linux 或 macOS 系统中，最简单的合并导入命令是：
cat dump_*.sql | mysql -u root -p mydb。请注意，通配符*默认按 ASCII 码排序。对于dump_00、dump_01这类零填充的命名有效，但对于dump_1.sql、dump_10.sql则可能出现排序错误。 - 若分卷文件采用了非零填充的数字命名，为确保万无一失，请使用更健壮的命令：
printf '%s\n' dump_*.sql | sort -V | xargs cat | mysql -u root -p mydb。其中sort -V可实现“自然排序”，正确处理版本号格式的文件名。 - Windows 用户请注意：切勿直接双击
.sql文件，这只是在编辑器中打开。正确的导入方式是在命令行中执行：type dump_00.sql dump_01.sql | mysql -u root -p mydb。
mysqldump 分卷前的关键参数配置：避免 --single-transaction 与 --lock-tables 的冲突
这是一个常见但致命的配置错误：同时启用 --single-transaction 和 --lock-tables 参数。在导出大型表时，这极易引发锁等待超时，导致 mysqldump 进程挂起或异常退出。其后果是，split 生成的最后一个分卷文件可能丢失关键的结束语句（如 UNLOCK TABLES; 或 COMMIT;），致使后续导入无法完成。
- 对于主要使用 InnoDB 存储引擎且读写频繁的线上数据库，推荐使用
--single-transaction参数。它通过 InnoDB 的多版本并发控制（MVCC）来获取一致性数据快照，不会锁定表。此时，务必不要使用--lock-tables。 - 如果数据库中包含 MyISAM 表，则必须使用
--lock-tables来保证导出数据的一致性。但请牢记，在这种情况下绝对不能再添加--single-transaction参数，否则mysqldump会静默忽略--lock-tables并产生警告。 - 良好的操作习惯是，在正式执行导出前，先添加
--verbose参数运行一次，以确认最终生效的选项组合，避免被配置文件中的默认参数覆盖。 - 若在命令行中看到密码安全警告，建议将数据库凭证配置在
~/.my.cnf文件中，以提升安全性。
为什么不能使用 MySQL 的 source 命令直接导入分卷文件
MySQL 客户端内置的 source（或其缩写 \.）命令仅接受单个文件路径，不支持管道输入或通配符。如果您尝试在 MySQL 命令行中依次执行 source dump_00.sql; 和 source dump_01.sql;，第二个文件很可能因为会话状态不一致（如前一个文件未完成的事务）而执行失败。
source命令的原理是客户端读取本地文件内容并逐条发送到服务器执行。它无法感知多个分卷文件之间的逻辑连续性，也不会自动恢复上一个文件结束时的数据库会话状态。- 唯一安全的交互式导入方法是：退出
mysql客户端，返回操作系统 Shell，使用前述的cat命令（或针对压缩文件的zcat命令）将所有分卷合并后，再通过管道重定向导入数据库。 - 此外，如果原始 SQL 文件开头包含
USE mydb;语句，请确保在合并后的完整文件中，该语句之前没有其他切换数据库的指令，以防数据被意外写入错误的库。
总结来说，分卷操作的技术本身并不困难，但事后的验证环节至关重要。切割完成后，应立即使用 head -n 20 和 tail -n 20 命令检查每个分卷文件的开头和结尾，确保 SQL 语法完整。建议随机抽取一个分卷，使用类似 mysql -u root -p -e "SELECT 1;" && echo ok 的命令快速测试数据库连接与权限。这些验证步骤不可或缺，稍有疏忽便可能导致整个备份失效，需要重新进行完整的导出操作。
