不能在phpMyAdmin中仅靠分表导出解决超大SQL文件问题，因其无法保障外键依赖、触发器、存储过程等跨对象一致性，且不支持真正意义上的分卷；可靠方案需用mysqldump --skip-extended-insert配合split -b按字节切分，并严格按序拼接导入。
直接用 phpmyadmin 导出超大数据库，生成一个几 gb 的 sql 文件，基本没法导入——不是上传失败，就是执行超时、连接中断或 error 1064。真正能落地的拆分方案，只有命令行组合，phpmyadmin 本身不支持分卷导出。
为什么不能在 phpMyAdmin 界面里“分表导出”就完事？
分表导出适合表数量少、单表不大、且你明确知道哪些表可拆开处理的场景。但一旦涉及外键依赖、触发器、存储过程或跨表事务一致性（比如订单+订单明细），单独导出几张表再分别导入，极大概率导致 ERROR 1215 (HY000): Cannot add or update a child row 或数据错位。它不是“拆分”，只是“挑着导”，不能解决单文件过大这个根本问题。
- 导出时若勾选了
ADD DROP TABLE和IF NOT EXISTS，各表之间仍存在隐式执行顺序依赖 - 视图、函数、事件等对象默认不随表导出，需额外勾选“数据库系统”部分
- 字符集与排序规则（如
utf8mb4_0900_as_cs）若未统一指定，导入时可能报ERROR 1273
用 mysqldump + split 实现可靠分卷的三个硬性条件
这是目前最稳定、被生产环境反复验证过的分卷方式，但必须同时满足以下三点，否则导入必失败：
- 必须加
--skip-extended-insert：让每条INSERT单独成行，避免一条语句被split截断 - 必须用
split -b（按字节切），不能用-l（按行切）：SQL 文件含注释、空行、多行定义（如CREATE PROCEDURE），行数切法完全不可控 - 必须禁用
--single-transaction和--lock-tables同时启用：二者叠加在大库上极易锁等待超时，导致导出中断、文件末尾缺COMMIT或UNLOCK TABLES
正确命令示例：
mysqldump -u root -p --skip-extended-insert --single-transaction mydb | split -b 400M -d --additional-suffix=.sql - dump_
生成 dump_00.sql、dump_01.sql…… 注意后缀和数字填充，确保 cat dump_*.sql 能按序拼接。
立即学习“PHP免费学习笔记（深入）”；
导入分卷文件时最容易忽略的致命点
每个 .sql 分卷都不是独立可执行脚本——dump_00.sql 结尾大概率是半截 INSERT 或未闭合的 CREATE TABLE。直接循环执行 mysql -u root -p mydb < dump_00.sql 会立刻报 ERROR 2013 (HY000): Lost connection to MySQL server during query。
- 必须先合并再导入：
cat dump_*.sql | mysql -u root -p mydb（Linux/macOS） - Windows 下不能用资源管理器双击打开，要用
type dump_00.sql dump_01.sql | mysql -u root -p mydb - 如果文件名是
dump_1.sql、dump_10.sql这种无前导零格式，*通配符会乱序，得改用：printf '%s\n' dump_*.sql | sort -V | xargs cat | mysql -u root -p mydb
真正麻烦的从来不是“怎么切”，而是切完能不能原样还原。所有跳过 --skip-extended-insert、用错 split 参数、或试图单个导入分卷的行为，都会让整个迁移卡在最后一步——看着一堆 .sql 文件，却连第一行都插不进去。
