根本原因是服务器上传限制被触发，而非文件格式问题；需同步调大php的upload_max_filesize和post_max_size、nginx的client_max_body_size，并合理设置max_input_time与max_execution_time。
这个错误根本不是文件格式问题，而是服务器在接收上传请求时被某道限制卡住了。你看到的 incorrect format parameter 是 phpmyadmin 对上游失败的“兜底提示”，它不反映 sql 文件本身是否损坏或编码错误，只说明 php 或 web 服务器没能完整拿到数据。
为什么 upload_max_filesize 和 post_max_size 必须同时调大
PHP 处理表单上传时，会先检查 post_max_size —— 它是整个 POST 请求体的总上限（含文件 + 表单字段）。只有当这个值够大，才会继续检查 upload_max_filesize（单个文件上限）。如果只改后者，而前者仍卡在默认的 8M，那么哪怕你把 upload_max_filesize 设为 500M，上传照样失败，且报错仍是 Incorrect format parameter。
-
post_max_size必须严格大于upload_max_filesize，建议至少多出 10MB - 两个值都必须用字母单位（如
256M），不能写成数字加空格（256 M会失效） - 修改后必须重启 PHP-FPM 进程，仅重载 Nginx 不生效
Nginx 的 client_max_body_size 为什么常被忽略
很多用户调完了 PHP 参数，还是失败，就是因为请求根本没进到 PHP 层。Nginx 在接收到 HTTP 请求头后，会立刻根据 client_max_body_size 判断是否允许接收请求体。一旦超限，它直接返回 413 Request Entity Too Large，但 phpMyAdmin 拦截不到这个状态码，只能抛出模糊的 Incorrect format parameter。
- 该参数需写在 Nginx 的 server 块或 http 块中，不能只加在 location ~ \.php$ 里
- 宝塔面板用户请进入「网站」→「设置」→「性能调整」，别只改「PHP 设置」
- 若使用 HTTPS，确保 SSL 配置块里也同步设置了该值，否则混合配置下可能失效
max_execution_time 和 max_input_time 的区别在哪
这两个时间限制作用阶段不同：max_input_time 控制的是“接收上传数据”的最大耗时，而 max_execution_time 控制的是“解析并执行 SQL”的耗时。大文件导入时，前者更容易先超时——尤其在网络不稳定或服务器负载高时，115MB 文件上传可能卡在 200 秒以上。
-
max_input_time默认为 -1（不限制）或 60 秒，低于 300 秒就很可能中断上传 -
max_execution_time影响的是导入后的 SQL 执行阶段，设太小会导致中途断掉、部分数据写入 - 两者都建议设为
300或更高，但不要设为0（无限），避免脚本失控占满资源
真正容易被忽略的是临时目录权限和字符集声明。即使所有大小和时间参数都调对了，如果 PHP 的 upload_tmp_dir 目录不可写，或者 SQL 文件开头没有 SET NAMES utf8mb4; 而数据库默认字符集不匹配，依然可能触发同一错误提示。排查时，先确认 phpinfo() 页面里 Loaded Configuration File 指向的确实是正在生效的 php.ini，而不是某个被覆盖的副本。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
