宝塔面板上传文件大小限制需同步修改Nginx的client_max_body_size、PHP的upload_max_filesize和post_max_size三处；超大SQL应绕过Web层，用mysql命令行导入并校验数据完整性。
宝塔面板上传文件大小限制在哪改
宝塔默认用 Nginx + PHP-FPM，上传限制是三处叠加的结果：Nginx 的 client_max_body_size、PHP 的 upload_max_filesize 和 post_max_size。改面板设置只能调后两者，但前端上传组件本身也有隐式限制（比如 2GB 就会卡住或报错 ERR_CONNECTION_RESET），所以单纯调大参数不解决根本问题。
- 修改
/www/server/panel/vhost/nginx/xxx.conf，在server块里加一行：client_max_body_size 4096m; - 在宝塔面板 → 网站 → 设置 → PHP 版本 → 配置修改，把
upload_max_filesize和post_max_size都设为4096M - 改完必须重启 Nginx 和 PHP：
bt restart或分别执行service nginx restart、service php-fpm-81 restart（版本号按实际填） - 即使全调到 4GB，超大 SQL（比如 >2GB）仍大概率失败——浏览器上传会超时、内存溢出、PHP 进程被 kill，这不是配置能兜住的
mysql 命令行导入大 SQL 文件的正确姿势
绕过 Web 层，直接走 MySQL 客户端导入，是唯一可靠方案。关键不是“能不能导”，而是“怎么导才不中断、不乱码、不丢数据”。
- 先确认数据库编码：用
mysql -u root -p -e "SHOW CREATE DATABASE \`dbname\`;"查看CHARACTER SET，导入命令里必须显式指定，否则中文变??? - 推荐命令格式：
mysql -u root -p --default-character-set=utf8mb4 dbname （注意不是 <code>-e，也不是用source） - 如果 SQL 文件含
CREATE DATABASE或跨库语句，先用mysql -u root -p ，让 MySQL 自动识别上下文 - 导入中途断了？加
--force参数继续跑（mysql -u root -p --force dbname ），它会跳过报错语句继续执行，适合含重复主键或已存在表的场景
导入卡住或报错 ERROR 2006 / 2013 怎么办
这是典型网络连接超时或包过大导致的 MySQL 断连，不是文件问题。命令行导入时没反馈不等于没在跑，得看进程和日志。
- 查进程是否还在：
ps aux | grep mysql，如果看到mysql ... 且 CPU 占用稳定，说明正在读取，别急着 Ctrl+C - ERROR 2006（MySQL server has gone away）：通常是
max_allowed_packet太小，登录 MySQL 后执行：SET GLOBAL max_allowed_packet = 1073741824;（1GB），再重试 - ERROR 2013（Lost connection to MySQL server during query）：检查
wait_timeout和interactive_timeout，临时设大：SET GLOBAL wait_timeout = 28800; SET GLOBAL interactive_timeout = 28800; - 别用
source导入大文件：mysql> source /path/to/file.sql是单线程逐行执行，遇到大 BLOB 或长事务极易崩
如何确认导入完成且数据完整
命令行返回 shell 提示符 ≠ 导入成功。MySQL 可能静默跳过错误，尤其用了 --force；也可能只写入了前半部分。
- 导入命令结束后，立刻查行数对比：
mysql -u root -p -e "SELECT COUNT(*) FROM dbname.table_name;"，和源 SQL 中的INSERT行数（可用grep -c "^INSERT" large.sql估算）大致核对 - 检查关键表的
AUTO_INCREMENT值是否合理：SHOW TABLE STATUS LIKE 'table_name';，如果还是 1，大概率没写进去 - 查错误日志：
tail -n 100 /www/server/mysql/logs/error_log，重点找Got timeout reading communication packets或Duplicate entry类提示 - 真正保险的做法：导入前用
mysqldump --no-data备份结构，导入后用mysqldump --no-create-info抽样导出几万行，和原 SQL 片段diff校验
大 SQL 导入最不可靠的环节永远是“以为它结束了”。进度看不见，错误藏得深，字符集、packet、timeout 全是暗坑——老老实实用命令行，盯住进程和日志，比调面板参数实在得多。
