超时不是脚本慢，而是php.ini、config.inc.php和MySQL的max_allowed_packet三重限制叠加卡死；需同步调高upload_max_filesize与post_max_size、设$cfg['ExecTimeLimit']=0、增大max_allowed_packet至256M，并用命令行导入更可靠。
phpMyAdmin 4.8 导入超时不是脚本慢，是三层限制卡死
直接结论：你看到的“script timeout passed”或白屏，99%不是服务器性能问题，而是 php.ini、config.inc.php 和 mysql 的 max_allowed_packet 三处配置没同步调高，任一漏改都会失败。
为什么改了 max_execution_time 还报错？
因为 phpMyAdmin 4.8 自带独立计时器，完全不认 PHP 的 max_execution_time。它用的是自己的 $cfg['ExecTimeLimit']，默认 300 秒，到点就主动中断，页面弹窗报错。
- 必须编辑 phpMyAdmin 根目录下的
config.inc.php（不是config.default.php），在$cfg['blowfish_secret']后加一行：$cfg['ExecTimeLimit'] = 0; - 设为
0表示禁用该限制；设为600表示 10 分钟，更稳妥 - 改完不用重启 Apache/Nginx，但必须清空浏览器缓存或换无痕窗口重进 phpMyAdmin 才生效
上传阶段就失败？别只盯 upload_max_filesize
错误提示 “file exceeds upload_max_filesize” 很具迷惑性——真正拦路的是 post_max_size 和 Nginx 的 client_max_body_size，它们比 upload_max_filesize 更早截断请求。
-
post_max_size必须 ≥upload_max_filesize，建议设为后者的 1.5 倍（如upload_max_filesize = 512M→post_max_size = 768M） - 宝塔或自建 Nginx 环境下，还需在站点配置的
server块里加：client_max_body_size 512M;，然后重载 Nginx - 确认你改的是 PHP-FPM 对应的
php.ini：访问phpinfo()页面查Loaded Configuration File路径，别改错文件
导入中途卡住/变白屏？MySQL 拒收大包了
WordPress 或导出含百万级 INSERT 的 SQL 文件，单条语句常超 10MB。max_allowed_packet 默认仅 4MB，MySQL 静默丢弃，不报错，只让页面卡死或断连。
- 临时验证：登录 MySQL 执行
SHOW VARIABLES LIKE 'max_allowed_packet'; - 永久生效：编辑 MySQL 配置文件（Windows 是
my.ini，Linux/macOS 是my.cnf），在[mysqld]下加：max_allowed_packet = 256M，然后重启 MySQL 服务 - 导入前务必先在 phpMyAdmin 左侧点击目标数据库名，确保顶部显示
数据库名 »，否则即使配置全对也会报#1046 - No database selected
最麻烦的从来不是单个参数，而是你调高了 upload_max_filesize 却忘了 post_max_size，或者改了 PHP 却没动 Nginx 或 MySQL 配置——它们像三道闸门，缺一不可。命令行导入 mysql -u root -p 数据库名 < file.sql 绕过全部 Web 层限制，才是 GB 级文件的首选路径。
立即学习“PHP免费学习笔记（深入）”；
