根本原因是PHP的upload_max_filesize和post_max_size配置过小，需通过phpinfo()确认真实生效的php.ini路径及当前值，同步修改upload_max_filesize、post_max_size（≥前者）、memory_limit（≥后者），单位用M，改后必须重启Web服务。
根本原因是 PHP 的 upload_max_filesize 和 post_max_size 配置太小，不是 phpMyAdmin 本身限制，改错地方或只改一个值都无效。
怎么确认当前上传限制值
别猜路径、别凭经验改配置。最可靠的方式是让 phpMyAdmin 自己告诉你它正在用哪个 php.ini：
- 在 phpMyAdmin 根目录新建一个
info.php文件，内容为<?php phpinfo(); ?> - 浏览器访问
http://your-domain/phpmyadmin/info.php - 搜索
Loaded Configuration File，看到的路径才是真实生效的php.ini - 再搜索
upload_max_filesize、post_max_size、memory_limit，记下当前值
常见默认值是 2M 或 8M，而实际 SQL 文件常达几十 MB，必然超限。
必须同步修改的三个 PHP 配置项
只改 upload_max_filesize 是最常见的失败原因。这三个值必须协同调整，且有明确大小关系：
立即学习“PHP免费学习笔记（深入）”；
-
upload_max_filesize = 256M：控制单个文件上限 -
post_max_size = 256M：必须 ≥upload_max_filesize，否则整个 POST 请求会被截断 -
memory_limit = 512M：导入时 phpMyAdmin 会把 SQL 内容读入内存解析，太小会导致中途崩溃
单位统一用 M（不是 MB），改完保存后必须重启 Web 服务（Apache 或 PHP-FPM），仅重载配置不生效。
为什么改了还是失败？这些坑最常被忽略
即使上传成功，后续仍可能卡死或报错，问题已从“上传阶段”转移到“执行阶段”：
- phpMyAdmin 不支持未选库直接导入：必须先在左侧点击目标数据库，再进「导入」页，否则含
CREATE DATABASE或USE `xxx`的语句会被跳过 - MySQL 层还有
max_allowed_packet限制：哪怕文件顺利上传，一条含大 JSON 或 Base64 的 INSERT 也可能触发ER_NET_PACKET_TOO_LARGE错误，需在 MySQL 配置中调大并重启 MySQL 服务 - 前端 JS 超时或内存溢出：phpMyAdmin 把整个 SQL 加载进浏览器再发请求，>50MB 的文件极易失败；此时
max_execution_time和$cfg['ExecTimeLimit']再怎么调都只是延缓崩溃
50MB 以上文件，直接用命令行导入最稳
绕过所有 PHP 和前端限制，本质是换掉传输通道：
- 确保 SQL 文件已上传到服务器（如
/www/backup/data.sql） - 确认 MySQL 服务正在运行（宝塔首页看状态，或执行
systemctl status mysql） - 执行命令：
mysql -u root -p your_database_name - 如果提示
command not found，用完整路径：/www/server/mysql/bin/mysql -u root -p your_database_name
注意：命令行导入不经过 PHP 上传流程，不受 upload_max_filesize 限制，也不依赖浏览器内存，是处理大文件的实际标准做法。
真正卡住人的从来不是“怎么改配置”，而是改完没重启、改了 CLI 版 php.ini 却忘了 Web SAPI 版本、或者以为上传成功就万事大吉——其实 MySQL 的 max_allowed_packet 和未选库导致语句跳过，才是静默失败的主因。
