许多用户在通过 phpMyAdmin 导入较大数据文件时，往往遇到这样的困扰：明明修改了 PHP 的 max_execution_time，甚至直接设为 0，却依然弹出“Script timeout passed”错误。实际上，这其实是一个常见的误区——你调整的只是 PHP 底层执行上限，但 phpMyAdmin 自身还含有一套独立的计时机制。
为何改了 max_execution_time 仍提示“Script timeout passed”？
phpMyAdmin 的导入流程隐藏着两套超时机制。PHP 的 max_execution_time 属于底层硬性限制，但 phpMyAdmin 的前端逻辑会主动读取自身配置项 $cfg['ExecTimeLimit']（默认 300 秒），每执行一段代码便会检查一次。即便你将 PHP 的值调到 3600，只要 $cfg['ExecTimeLimit'] 未同步修改，它照样会在 300 秒时中断连接。
解决方式其实很简单：
- 打开
XAMPP/phpMyAdmin/config.inc.php（注意不是config.default.php） - 添加或修改
$cfg['ExecTimeLimit'] = 0;（设为 0 表示禁用超时） - 修改完成后清空浏览器缓存，或改用无痕窗口重新进入 phpMyAdmin——无需重启 Apache
导入中途卡住、白屏、无报错？先检查 max_allowed_packet
这种情况实际并非超时，而是 MySQL 拒绝接收整条语句。比如一条包含 10MB JSON 字段的 INSERT，若超过服务端缓冲区上限，MySQL 会直接静默丢包，phpMyAdmin 便卡在“正在导入…”状态不动。
如何排查？先确认当前值：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"- 临时提高（仅本次会话）：
SET GLOBAL max_allowed_packet = 268435456;（256MB） - 永久生效：编辑
my.ini（Windows）或my.cnf（macOS/Linux），在[mysqld]下添加max_allowed_packet = 256M - 修改后必须重启 MySQL 服务，否则不生效
nginx/apache 报 504 Gateway Timeout？那是网关先撑不住了
PHP 脚本或许仍在运行，但 nginx 或 apache 等不到响应便主动断开连接。这个超时与 PHP 完全无关，需要单独调整。
- Nginx 用户：检查
location ~ \.php$块中的fastcgi_read_timeout，至少应比max_execution_time大 20 秒 - Apache + mod_php：确认
Timeout指令（主配置或虚拟主机内）已适当调高，避免使用默认的 60 秒 - 如果使用了 Cloudflare？免费版硬性限制 100 秒超时，无法绕过，只能选择直连或升级套餐
真正可靠的大文件导入方式：绕过 phpMyAdmin
命令行导入不经过 HTTP 请求、PHP 解析、进度渲染这三层瓶颈，也不受 $cfg['ExecTimeLimit']、post_max_size、max_execution_time 任何一项的影响。
操作步骤：
- 确保 MySQL 已运行（XAMPP 面板显示 Running）
- 在终端进入
XAMPP/mysql/bin目录，执行：mysql -u root -p --default-character-set=utf8mb4 your_db_name - 登录后输入：
source C:/path/to/your/file.sql;（路径使用正斜杠，Windows 同样适用） - 如果 SQL 包含大量
INSERT，导入前手动添加：SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;，导入后恢复原设置
最容易被忽略的一点：命令行导入失败时，错误信息往往比 phpMyAdmin 更加具体——例如字符集不匹配、权限不足、SQL 语法嵌套过深（如 DELIMITER 未正确闭合）。这些错误在 Web 界面中常被吞掉，或直接显示为白屏。因此，别说命令行麻烦，关键时刻它才是真正的救命稻草。
