MySQL导入失败主因是max_allowed_packet过小（默认4MB），需调至256M并同步调整innodb_log_file_size；PHP侧需确保upload_max_filesize与post_max_size一致（如均设256M）且memory_limit≥512M；Web超时需同时设max_execution_time=300、request_terminate_timeout=300及Nginx fastcgi_read_timeout=300；超大文件建议用命令行导入。
MySQL 导入失败：max_allowed_packet 不够大
导入大 SQL 文件时卡住、报错或直接中断，大概率是 max_allowed_packet 太小。MySQL 默认值通常只有 4MB，而导出的数据库可能动辄几十 MB。它控制单条 SQL 语句或结果集的最大尺寸，不是“上传文件大小”，所以调 PHP 的 upload_max_filesize 没用。
- 登录宝塔 → 数据库 → 找到对应 MySQL 实例 → 点击“配置修改”
- 在配置文件中搜索
max_allowed_packet，改成256M（不建议超过 512M，过大可能引发内存问题） - 务必同时检查
innodb_log_file_size是否匹配——若该值远小于max_allowed_packet，仍可能写入失败 - 改完重启 MySQL，别只重载配置
PHP 侧上传被拦：post_max_size 和 upload_max_filesize 不一致
宝塔后台点击“导入”按钮后页面没反应、提示“文件为空”或 500 错误，常因这两个参数冲突。它们不是并列关系：post_max_size 必须 ≥ upload_max_filesize，否则即使文件传上去了，PHP 在解析 POST 体时也会直接丢弃。
- 进宝塔 → PHP 设置 → “配置修改” → 找到
upload_max_filesize和post_max_size - 设成相同值更稳妥，比如都设为
256M；memory_limit建议同步调高到512M，避免解析大 SQL 时内存溢出 - 注意：改的是当前网站所用的 PHP 版本配置，不是全局默认模板
- 改完重启 PHP，不重启的话参数不会生效
宝塔界面导入超时：max_execution_time 和 request_terminate_timeout
进度条走到一半不动、提示“连接已断开”或“504 Gateway Timeout”，本质是请求执行时间超限。宝塔前端走的是 Web 请求，受 PHP 执行时限和 Nginx 超时双重限制。
-
max_execution_time设为0（不限制）仅对 CLI 有效，Web 模式下仍会受request_terminate_timeout（Nginx FastCGI 超时）制约 - 进宝塔 → 网站 → 设置 → PHP 版本 → “禁用函数”旁有“超时时间”，填
300秒起手；再进“配置修改”，确认max_execution_time = 300 - 更重要的是：进“软件商店”→ 找到当前 Nginx → 设置 → “配置修改”，在
location ~ \.php$块里加一行：fastcgi_read_timeout 300; - 如果导入文件特别大（>200MB），建议放弃宝塔界面，改用命令行：
mysql -u root -p database_name
字符集不匹配导致乱码或语法错误
导入后中文变问号、字段名错乱、甚至报 You have an error in your SQL syntax，往往不是 SQL 文件损坏，而是服务端与文件的字符集不一致。宝塔默认新建数据库用 utf8mb4，但老导出文件可能是 latin1 或 utf8（非 utf8mb4）。
立即学习“PHP免费学习笔记（深入）”；
- 先用
file -i large.sql查看文件实际编码；再用mysql --help | grep "Default charset"看客户端默认字符集 - 导入前显式指定字符集：
mysql -u root -p --default-character-set=utf8mb4 database_name - 如果 SQL 文件头没有
SET NAMES utf8mb4或CREATE DATABASE ... DEFAULT CHARSET=utf8mb4，手动补上更稳 - 宝塔界面导入不支持传参，所以这一步必须命令行做
真正麻烦的从来不是改几个参数，而是改完漏掉某一个环节——比如调了 MySQL 却忘了 Nginx 超时，或者改了 PHP 配置却没重启对应进程。参数之间是咬合的，断一环，整个链路就停在那儿。
