Navicat 15 不支持按大小分卷导出，超大库易因内存溢出或I/O错误导致SQL文件截断；必须用 mysqldump --skip-extended-insert --single-transaction | split -b 800M -d --additional-suffix=.sql 分卷，并确保 max_allowed_packet 足够、MyISAM表改用 --lock-tables。
Navicat 15 本身不支持分卷导出，强行用界面导出超大库（如 >2GB）极易因内存溢出、临时文件写入失败或中断导致 SQL 文件末尾截断——表现为导入时卡在 ERROR 2013 (HY000) 或 ERROR 1064。必须绕过 GUI，用 mysqldump + split 组合实现可控分卷。
为什么不能直接用 Navicat 的“转储SQL文件”分卷？
Navicat 没有“按大小分卷”选项；它要么导出单个完整文件，要么在导出中途崩溃后留下损坏的半成品。常见现象包括：
- 导出进度条卡在 99%，最终生成的 .sql 文件比预期小，
tail -c 100 dump.sql显示结尾不是;或UNLOCK TABLES; - 导出路径含中文或 OneDrive 同步目录，触发
Disk I/O Error，但 Navicat 不提示具体原因 - 勾选了
--single-transaction和--lock-tables同时启用，在大表上锁等待超时，导致 mysqldump 进程被 kill，split 接到的是不完整流
正确做法：用 mysqldump + split 管道分卷
关键不是“切得开”，而是“切得准”——每一片都必须以完整 SQL 语句结尾，否则无法单独拼接导入。
- 必须加
--skip-extended-insert：确保每行一条INSERT，避免单条语句跨 split 边界 - 必须用
split -b（字节切），不能用-l（行数切）：SQL 文件里有注释、空行、多行字符串，行数切会直接撕裂语句 - 命名用
-d --additional-suffix=.sql：生成dump_00.sql、dump_01.sql，数字补零便于后续cat dump_*.sql正确排序 - 导出命令示例：
mysqldump -u root -p --skip-extended-insert --single-transaction mydb | split -b 800M -d --additional-suffix=.sql - dump_
导入前必须检查的三个细节
分卷文件不是独立可执行脚本，直接双击或逐个运行必报错。
-
dump_00.sql结尾大概率是半截INSERT INTO ... VALUES (，不能单独mysql -u root -p mydb - Linux/macOS 下合并执行必须用：
cat dump_*.sql | mysql -u root -p mydb（*默认 ASCII 排序，dump_00在dump_01前） - Windows 下不能用资源管理器双击打开，必须进 cmd：
type dump_00.sql dump_01.sql | mysql -u root -p mydb；若文件名无补零（如dump_1.sql,dump_10.sql），需先dir /b dump_*.sql | sort /V确认顺序 - 导入前务必确认 MySQL 服务端
max_allowed_packet≥ 单片最大体积（比如设为1024M），否则ERROR 1153 (08S01)会静默截断接收
最易被忽略的一点：分卷导出时若数据库含 MyISAM 表，--single-transaction 无效，必须改用 --lock-tables，但此时绝对不要加 --single-transaction，否则锁冲突会让 mysqldump 中断，split 接收的流不完整——这种损坏无法靠肉眼识别，只能靠导入时报错倒推。
