必须同步修改Nginx的client_max_body_size、PHP的upload_max_filesize和post_max_size（后者≥前者）、MySQL的max_allowed_packet，漏任一层都会失败；宝塔中需在对应模块正确配置并重启服务，超50MB文件建议直接用mysql命令行导入。
不能只改 phpMyAdmin 的配置，它本身不控制上传大小——真正卡住你的是 Nginx、PHP 和 MySQL 三层限制，漏掉任意一层都会失败。
必须同步修改的三个关键参数
phpMyAdmin 导入大 SQL 文件时，请求要依次经过 Nginx → PHP → MySQL。每一层都有独立的大小限制，且互不感知：
-
client_max_body_size（Nginx 层）：决定整个 HTTP 请求体能否被接收。若设为50M，哪怕 PHP 允许 2G，Nginx 在入口就返回 413 错误，请求根本到不了 PHP -
upload_max_filesize和post_max_size（PHP 层）：前者管单个文件，后者管整个 POST 数据总量；post_max_size必须 ≥upload_max_filesize，否则 PHP 会静默丢弃数据 -
max_allowed_packet（MySQL 层）：不是文件大小限制，而是单条语句或结果包的最大长度。含 BLOB、长文本或超长 INSERT 的 SQL 文件极易触发Got a packet bigger than 'max_allowed_packet' bytes
宝塔面板里怎么改才真正生效
在宝塔中操作时，最容易踩的坑是“改了没重载”或“改错位置”：
- Nginx 配置：进【网站】→【对应站点】→【配置文件】，在
server {块开头插入client_max_body_size 512M;（别写在location /phpmyadmin内部，优先级易被覆盖） - PHP 配置：进【软件管理】→【PHP 版本】→【配置修改】，把
upload_max_filesize = 512M和post_max_size = 512M改完后，**必须点「保存」再点「重启」**（不是「重载」），否则 php-fpm 进程仍用旧配置 - MySQL 配置：编辑
/www/server/mysql/my.cnf，在[mysqld]段下加max_allowed_packet = 512M（单位必须是大写M），然后执行service mysqld restart - 验证是否生效：建一个
info.php（内容<?php phpinfo(); ?>），访问后搜索三项值；再用命令mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"确认 MySQL 已更新
为什么改完还是报 Incorrect format parameter
这个错误不是格式问题，是上游拦截后的“甩锅式提示”。常见真实原因：
立即学习“PHP免费学习笔记（深入）”；
- 浏览器 Network 标签页看到响应状态码是
413→ Nginx 没生效，检查配置是否写在正确作用域、是否漏重启 - 页面空白或卡住几秒后跳回导入页 → PHP 超时，顺手调高
max_execution_time = 3600和memory_limit = 1024M - 导入中途中断、部分表缺失 → SQL 文件含
SET FOREIGN_KEY_CHECKS=0但结尾没恢复，或字符集声明不一致（建议用iconv -f GBK -t UTF-8 input.sql > output.sql统一转码） - 宝塔启用了「防跨站攻击」或 WAF 插件 → 进【网站】→【设置】→ 关闭「防跨站攻击」临时测试；或 F12 看 Network 中上传请求是否被 JS 拦截
50MB 以上文件建议直接跳过 phpMyAdmin
硬调参数只是权宜之计，越大的文件越容易因超时、内存溢出或网络抖动失败。更稳的方式是绕过 Web 层：
- 把 SQL 文件传到服务器（如
/www/backup/large.sql） - 确认文件无
CREATE DATABASE或USE语句（避免误操作） - 执行：
mysql -u root -p your_db_name - 如果提示
command not found，用完整路径：/www/server/mysql/bin/mysql -u root -p your_db_name
命令行导入不受任何上传限制，且能实时看到报错位置，排查效率高得多。真正麻烦的从来不是改哪几个值，而是改完忘了重启服务，或者改了 Nginx 却以为 PHP 已经够用了。
