单纯调大php.ini参数常无效，因128MB+ SQL文件超phpMyAdmin前端上传能力；必须同步设upload_max_filesize、post_max_size、memory_limit、max_execution_time=0及$cfg['ExecTimeLimit']=0；最优解是配置$cfg['UploadDir']走本地导入，彻底绕过HTTP上传限制。
改 php.ini 不能单独解决问题，尤其对 128MB+ 的 SQL 文件，它只是第一步，且常被高估——多数失败根本不在 PHP 层，而在 phpMyAdmin 前端上传链路或 MySQL 自身限制。
为什么单纯调大 upload_max_filesize 往往无效
即使你把 upload_max_filesize、post_max_size 和 memory_limit 全设为 512M，仍大概率遇到：
-
No data was received to import错误：浏览器上传中途断连、PHP 超时（max_execution_time）、或 phpMyAdmin 内部校验拒绝大文件 - 导入页面卡死/空白：SQL 解析阶段内存爆掉，因为 phpMyAdmin 会把整个文件读入内存再分块执行
- 虚拟主机或 Docker 环境下根本无法修改
php.ini，或改了不生效（如 CLI 与 FPM 配置分离）
必须同步调整的 php.ini 参数（仅当有权限且必须走 HTTP 上传时）
若你确认要保留“前端点击上传”流程（比如没权限配 $cfg['UploadDir']），以下参数缺一不可：
-
upload_max_filesize = 512M（注意单位必须是 M 或 G，不能写 512000000） -
post_max_size = 512M（必须 ≥upload_max_filesize） -
memory_limit = 1024M（phpMyAdmin 解析 SQL 时吃内存，128MB 文件常需 >500MB 内存） -
max_execution_time = 0（设为 0 表示不限时；设数值如 600 容易在慢查询时中断） -
max_input_time = -1（部分环境需显式禁用输入超时）
改完后必须重启 Web 服务（如 systemctl restart apache2 或 service php-fpm restart），仅 reload 不够。
更关键的是：phpMyAdmin 自身的执行时限
php.ini 的 max_execution_time 控制 PHP 总体脚本时间，但 phpMyAdmin 5.2 还有一层独立限制：
- 打开
config.inc.php，确保存在且生效：$cfg['ExecTimeLimit'] = 0; - 这个值优先级高于 php.ini 的
max_execution_time，不设为 0，即使 php.ini 放开，导入页仍会在 300 秒强制终止 - 注意：该配置项必须放在
$cfg['Servers']数组定义之后，否则被忽略
真正绕过瓶颈的路径不是调 php.ini，而是跳过 HTTP 上传
所有实操经验指向一个事实：128MB 是 phpMyAdmin 前端上传的事实天花板。一旦超过，$cfg['UploadDir'] 是唯一稳定解法——它让 phpMyAdmin 直接读服务器本地文件，完全不经过 upload_max_filesize 校验、不触发浏览器上传、不消耗 PHP 内存做解析。
这意味着：你花两小时调 php.ini，不如花 10 分钟配好 $cfg['UploadDir'] 并把文件丢进对应目录。而后者失败时，问题一定出在 MySQL 层（如 max_allowed_packet 太小），排查路径清晰、可控。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
