phpmyadmin 无法限制上传大小和类型，需从 nginx/apache 和 php 层级配置 client_max_body_size、upload_max_filesize、post_max_size，并禁用上传目录脚本执行，且须确认 php-fpm pool 配置生效。
不能靠 phpmyadmin 自身配置来「限制」上传大小和类型——它压根不校验文件类型，大小限制也只在前端显示，后端全靠 php 和 web 服务器兜底。真要防大文件或恶意文件，得从 nginx / apache + php 层级下手。
413 错误是 Nginx 拦的，不是 phpMyAdmin 或 PHP 报的
用户选完大 SQL 文件点「执行」后立刻报 413 Request Entity Too Large，这说明请求体根本没进 PHP。Nginx 在解析 HTTP 请求头/体阶段就拒掉了。
-
client_max_body_size必须写在server块，或者更精确地写在location /phpmyadmin { ... }块里（如果 phpMyAdmin 是子路径部署） - 值别设
0或off，推荐显式设为20M或50M；设太大等于放弃防御 - 改完必须运行
nginx -t && systemctl reload nginx，否则配置不生效
PHP 层 upload_max_filesize 和 post_max_size 必须 ≤ Nginx 的 client_max_body_size
Nginx 放行之后，PHP 才会开始解析 POST 数据。这时两个 ini 项才起作用：
-
upload_max_filesize控制单个文件上限（比如你只传一个dump.sql） -
post_max_size控制整个 POST 请求体上限（含文件 + 表单字段），必须 ≥upload_max_filesize - 它们都得小于等于 Nginx 的
client_max_body_size，否则会出现「Nginx 放了，PHP 又拦」的错乱现象 - 注意：如果你用 PHP-FPM，要改对应 pool 的
php_admin_value[upload_max_filesize]，不是全局php.ini
phpMyAdmin 不校验文件类型，.sql 后缀可被绕过
phpMyAdmin 的 import 页面只检查扩展名是否在白名单（sql, csv, xml 等），但这个检查纯前端 JS，且服务端 import.php 几乎不验证 MIME 类型或内容。攻击者只要把恶意 PHP 脚本改成 shell.sql 就能上传成功（如果其他层没拦）。
- 真正有效的类型控制得靠 Web 服务器：Nginx 可用
location ~ \.sql$ { deny all; }拦住所有直接访问 .sql 文件的请求（防上传后被下载或执行） - 上传目录（如
$cfg['UploadDir'] = 'upload';）务必禁止脚本执行：Nginx 中加location ^~ /phpmyadmin/upload/ { deny all; } - 别依赖 phpMyAdmin 的
$cfg['UploadDir']做安全隔离——它只是提供一个「从服务器本地选文件导入」的便利功能，不是上传入口
大 SQL 导入卡死或静默失败，本质是前端+超时双重陷阱
选中几百 MB 的 SQL 文件后浏览器假死、进度条不动、最终无提示失败——这不是 bug，是设计使然：phpMyAdmin 用传统 <form enctype="multipart/form-data"></form> 提交，浏览器得先把整个文件读进内存再发，期间无分块、无进度、无重试。
-
max_execution_time和max_input_time对「上传阶段」完全无效；上传耗时由 Nginx 的client_header_timeout和client_body_timeout控制 - 前端卡死无法通过调大 PHP 参数解决，唯一可靠解法是绕过 Web 界面：
mysql -u user -p database - 如果非要用 Web 界面，确保服务器与浏览器时区一致，避免因时间偏差导致 session 或 CSRF token 提前失效
最常被忽略的一点：你以为改了 php.ini 就完事，其实 phpMyAdmin 很可能跑在独立的 PHP-FPM pool 里，加载的是 /etc/php/*/fpm/pool.d/www.conf 里的 php_admin_value，而不是系统默认的 php.ini。不确认运行时配置来源，90% 的修改都是白忙活。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
