唯一可靠方案是跳过Web界面，用mysql命令行导入；因浏览器、PHP、Nginx构成不可靠链路，即使调高upload_max_filesize和client_max_body_size，MySQL自身wait_timeout与max_allowed_packet仍会中断导入。
直接改 PHP 和 Nginx 参数无法彻底解决超大 SQL 导入问题，尤其当文件超过 2GB 时，Web 层上传必然失败——这不是配置没调够，而是浏览器、PHP 进程、Nginx 缓冲区共同构成的不可靠链路。唯一稳的方案是跳过面板，走 mysql 命令行导入。
为什么改了 upload_max_filesize 还报 413？
Nginx 默认 client_max_body_size 是 1MB，它在请求进入 PHP 前就直接拦截并返回 413 Request Entity Too Large。只改 PHP 的 upload_max_filesize 和 post_max_size 完全无效。
- 必须在站点配置文件（
/www/server/panel/vhost/nginx/xxx.conf）的server块内添加：client_max_body_size 2048m; - HTTPS 站点还要在
server { listen 443 ssl; }块里重复加这一行 - 改完不能只点「重载配置」，得确认 Nginx 配置语法：执行
nginx -t，再systemctl reload nginx或宝塔里点「重载配置」 - 别手动改全局
/etc/nginx/nginx.conf，宝塔升级会覆盖
PHP 配置改哪些、怎么改才真正生效？
宝塔界面里进「软件商店 → PHP → 设置 → 配置修改」是最稳妥路径，但必须同时改四项，缺一不可：
upload_max_filesize = 2048M-
post_max_size = 2048M（必须 ≥upload_max_filesize，否则表单提交直接拒） -
max_execution_time = 3600（默认 30 秒，大 SQL 解析就超时） -
memory_limit = 1024M（upload_max_filesize超过 512M 时，内存常被吃光） - 改完必须点「保存」并等宝塔提示「PHP 服务已重启」，仅「重载配置」不生效
phpMyAdmin 导入大 SQL 为什么静默丢数据？
宝塔内置的 phpMyAdmin 是精简版，对 >100MB 的 SQL 文件解析极不稳定，且不报错、不中断、不提示失败——它会跳过建表冲突、主键重复、字符集不匹配等语句，你以为导入成功，其实表结构或中文字段已经残缺。
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖其「从服务器上传目录导入」功能，
upload目录权限设为 755 也没用 - 检查 SQL 文件开头是否有
SET NAMES utf8mb4;，没有就手动加，否则中文入库成??? - 用 VS Code 打开 SQL 文件，确认编码是 UTF-8 无 BOM；BOM 会导致首行执行失败，后续全跳过
- 真要走 Web 界面，优先用独立部署的 phpMyAdmin（非宝塔内置），但依然不如命令行可靠
命令行导入才是唯一可信赖路径
把 SQL 文件上传到服务器任意目录（如 /www/backup/db.sql），然后终端执行：
mysql -u root -p --default-character-set=utf8mb4 dbname < /www/backup/db.sql
关键点：
- 不用先登录 MySQL，
<重定向方式比source更稳定 - 务必加
--default-character-set=utf8mb4，否则可能乱码 - 如果中途报
ERROR 2006 (MySQL server has gone away)，说明max_allowed_packet太小，登录 MySQL 后执行：SET GLOBAL max_allowed_packet = 1073741824; - 导入过程无进度条，可用
ps aux | grep mysql看进程是否还在跑，别手抖 Ctrl+C
最易忽略的是：即使你把 Nginx、PHP、phpMyAdmin 全部调到 4GB，只要文件含大量 INSERT 或临时表操作，MySQL 自身的 wait_timeout 和 max_allowed_packet 仍会中断连接——这些参数不在面板里，只能进 MySQL 命令行临时设或写进 /etc/my.cnf 永久生效。
