直接导入大SQL分片失败因phpMyAdmin受upload_max_filesize、post_max_size和max_execution_time三重限制，且不支持分片顺序执行；须同步调大三值并重启服务，或改用mysql命令行导入。
为什么直接导入大SQL分片会失败
phpMyAdmin 默认限制单次上传文件大小（upload_max_filesize）和脚本执行时间（max_execution_time），即使你把一个 2GB 的 SQL 拆成 50MB/片，只要某一片超过 post_max_size（常见默认 8M 或 64M），上传阶段就直接报错：File too large. Please increase the value of upload_max_filesize in php.ini。更隐蔽的问题是：phpMyAdmin 的「导入」界面不识别分片之间的依赖顺序，也不会自动跳过已执行的语句——手动挨个点「执行」极易重复导入或中断报错。
必须改的三个 PHP 配置项
仅调大 upload_max_filesize 不够，这三个值必须同步调整并重启 Web 服务：
-
upload_max_filesize = 128M（单文件上限，建议设为最大分片体积的 1.5 倍） -
post_max_size = 128M（POST 数据总上限，必须 ≥upload_max_filesize） -
max_execution_time = 600（脚本超时，导入 100MB 级 SQL 通常需 2–5 分钟）
改完别忘了运行 sudo systemctl restart apache2（或 nginx + php-fpm），且确认 phpMyAdmin 页面右下角显示的「Max: xxx MB」已更新——这是唯一验证生效的方式。
用命令行替代 phpMyAdmin 导入分片
绕过所有 Web 层限制的最稳方案：在服务器终端直接执行 mysql 命令。假设分片文件按顺序命名：dump_part_001.sql、dump_part_002.sql…，数据库名为 mydb：
立即学习“PHP免费学习笔记（深入）”；
mysql -u root -p mydb < /path/to/dump_part_001.sql mysql -u root -p mydb < /path/to/dump_part_002.sql
关键细节：
- 确保每个分片末尾不含
USE `mydb`;或CREATE DATABASE，否则第二片开始会报错Unknown database - 如果分片含大量
INSERT，提前在首片开头加SET autocommit=0;，末片结尾加COMMIT;，能提速 3–5 倍 - 用
pv实时看进度：pv dump_part_001.sql | mysql -u root -p mydb
phpMyAdmin 中「勉强可用」的手动分片导入技巧
若只能用 Web 界面（如共享主机无 SSH 权限），必须满足两个前提：upload_max_filesize 已调至 ≥ 单片大小，且所有分片已去除外键约束（否则第二片可能因父表未建完而失败）：
- 进入 phpMyAdmin → 选中目标数据库 → 点「导入」→ 上传第一片 → 勾选「部分导入：忽略插入错误」（绕过重复主键等非致命错）
- 导入后立刻检查
information_schema.TABLES，确认表结构已建好、行数合理；若某片卡在「正在执行」超 2 分钟，立即关掉标签页——重试前先清空该表再重新导入此片 - 绝对不要用「从网页服务器上传目录」功能，它不支持分片，且路径权限常导致
Cannot open file
分片顺序错一位、少导入一片、或某片末尾缺分号导致语法截断——这类问题在 Web 界面里几乎无法定位，日志也不输出具体哪行出错。真要靠 phpMyAdmin 导入，务必留一份原始分片的校验和（sha256sum *.sql），导完立刻核对。
