根本原因是Nginx、PHP、phpMyAdmin三层配置共同限制上传——Nginx的client_max_body_size触发413错误，PHP的upload_max_filesize和post_max_size需同步调大并重启服务，phpMyAdmin的$cfg['MaxImportFileSize']需显式设置且单位为字节。
根本原因不是phpmyadmin本身限制，而是nginx、php、phpmyadmin三层配置共同卡住上传流程——任一环节超限都会触发 incorrect format parameter 或 413 request entity too large 错误。
为什么Nginx会直接拦截大文件上传
Nginx在收到HTTP POST请求时，会先检查请求体大小是否超过 client_max_body_size。一旦超出，它根本不会把请求转发给PHP，而是立即返回 413 Request Entity Too Large（状态码413），此时phpMyAdmin甚至没机会执行。
- 宝塔面板默认该值为 100M，但若你导入的是 200MB SQL 文件，就必须手动调高
- 修改位置：宝塔 → Nginx → 配置修改 → 在
http{}块内添加或修改client_max_body_size 512M; - 必须执行「重载配置」（不是重启），否则不生效；改完后可用
curl -X POST --data-binary @large.sql http://your-site.com/phpmyadmin/import.php测试是否仍报413
PHP的upload_max_filesize和post_max_size必须同步调大
即使Nginx放行了，PHP仍会按自己规则二次拦截。关键点在于：post_max_size 必须 ≥ upload_max_filesize，否则POST数据被截断，phpMyAdmin读到的是残缺内容，最终抛出 Incorrect format parameter。
- 宝塔中修改路径：网站 → PHP 设置 → 配置修改 → 找到并修改两行：
upload_max_filesize = 512M、post_max_size = 512M - 顺带调高
max_execution_time = 1200和memory_limit = 1G，避免导入中途超时或OOM - 改完必须「重启PHP服务」（不是重载），否则 phpinfo() 里看到的仍是旧值
phpMyAdmin自身也有隐藏限制
即使前两层都放开，phpMyAdmin 的 $cfg['MaxImportFileSize'] 仍可能强制截断——这个值默认未设置，会退回到PHP的 upload_max_filesize，但显式设小就会覆盖。
- 编辑宝塔中 phpMyAdmin 的
config.inc.php（通常在/www/server/phpmyadmin/下） - 在
$cfg['UploadDir'] = 'upload';后添加：$cfg['MaxImportFileSize'] = 536870912; // 单位是字节，512MB - 注意：该参数只影响界面显示的最大允许值，不替代PHP/Nginx限制；若设得比PHP值还大，实际仍以PHP为准
导入成功后仍可能丢数据？检查SQL文件头尾
命令行导入虽绕过上传限制，但大文件常含隐性陷阱：比如开头有 SET FOREIGN_KEY_CHECKS=0; 却没配对的 SET FOREIGN_KEY_CHECKS=1;，或结尾缺失 COMMIT;，导致部分事务未真正写入。
立即学习“PHP免费学习笔记（深入）”；
- 用
head -n 20 large.sql和tail -n 20 large.sql快速检查外键开关、字符集声明（如DEFAULT CHARSET=utf8mb4）、事务控制语句 - 导入后务必执行：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'your_db';核对表数量，再抽几个大表COUNT(*)确认行数 - 若用
mysql -u root -p db_name 导入失败且无提示，试试加 <code>-v参数看详细错误：mysql -v -u root -p db_name
最容易被忽略的是：Nginx重载、PHP重启、phpMyAdmin配置修改这三步缺一不可，且顺序不能颠倒——先Nginx，再PHP，最后改phpMyAdmin配置。漏掉任意一个，都可能让你反复看到那个似是而非的“格式参数错误”。
