典型现象是页面空白、400/502错误或提示upload_max_filesize超限，实为Nginx拦截；须在server或location块中配置client_max_body_size 512M、client_body_buffer_size 128k、client_body_timeout 300，并验证生效。
phpMyAdmin 导入大 SQL 失败的典型现象
点击“导入”后页面直接空白、返回 400 或 502 错误，或上传后提示 The uploaded file exceeds the upload_max_filesize directive in php.ini——但你已经改过 php.ini，说明问题不在 PHP 层，而在 Nginx 拦截了请求体。
必须调整的三个 Nginx 参数
Nginx 默认限制客户端请求体大小（尤其是 POST），而 phpMyAdmin 导入本质是 multipart/form-data POST 请求。仅调大 PHP 的 upload_max_filesize 和 post_max_size 不够，Nginx 会在到达 PHP 前就拒绝请求。
在对应站点的 Nginx 配置块（通常是 /etc/nginx/sites-enabled/your-phpmyadmin.conf）中，server 或 location 块内添加或修改以下三项：
-
client_max_body_size 512M;—— 控制整个请求体上限，建议设为略大于你要导入的 SQL 文件（如 512M、1G） -
client_body_buffer_size 128k;—— 缓冲区大小，太小会导致频繁写临时文件；设为128k或256k即可，不必过大 -
client_body_timeout 300;—— 上传超时时间（秒），大文件上传慢，避免中途断连；300 秒（5 分钟）较稳妥
注意：client_max_body_size 必须放在 server 或 location 块里，不能只写在 http 全局块（除非你确定所有站点都要放宽）。
立即学习“PHP免费学习笔记（深入）”；
为什么 reload 后仍不生效？检查常见位置冲突
很多用户改完配置 reload 成功，但导入还是失败——大概率是 Nginx 配置被多处覆盖：
- 确认修改的是实际生效的配置文件（用
nginx -t测试 +nginx -T | grep client_max_body_size查看最终合并值） - 检查是否有
include引入的子配置（如fastcgi_params或自定义php.conf）覆盖了location ~ \.php$块内的设置 - phpMyAdmin 若通过子目录访问（如
/phpmyadmin），需确保location /phpmyadmin/块里也包含上述参数，或至少继承自外层server - 某些一键包（如宝塔、AMH）会把 phpMyAdmin 单独映射为反向代理，此时 Nginx 参数要加在 proxy 所在的 server 块，而非后端 PHP 的 server 块
验证是否真正生效的快速方法
别等导入失败再排查。用 curl 模拟一个超限 POST 请求来验证：
curl -X POST http://your-domain/phpmyadmin/import.php \ -F "upload=1" \ -F "MAX_FILE_SIZE=536870912" \ -F "import_file=@/dev/zero" \ --data-binary @/dev/zero \ --max-time 10
如果返回 413 Request Entity Too Large，说明 client_max_body_size 仍不足；若返回 500 或空白，问题可能出在 PHP 或 phpMyAdmin 自身（比如 memory_limit 不够）。另外，Nginx 错误日志（/var/log/nginx/error.log）里出现 client intended to send too large body 就是它拦的。
参数调得太大也没用：超过 2G 容易触发 Nginx 内部整数溢出，且 phpMyAdmin 本身对超大 SQL 解析效率极低，真要导 >1G 的库，不如用命令行 mysql 客户端直连导入。
