根本原因是php的max_execution_time、phpmyadmin的$cfg['exectimelimit']及mysql的max_allowed_packet三重限制共同导致；需分别修改php.ini、config.inc.php和my.cnf，并验证各层生效，缺一则失败。
phpmyadmin 导入大 sql 文件提示执行超时，根本不是数据库慢或网络卡，而是 php 脚本在解析和执行过程中被主动掐断——max_execution_time 是第一道关，但往往你改了它，还是超时，因为还有 $cfg['exectimelimit'] 和 mysql 的 max_allowed_packet 在背后卡着。
为什么改了 max_execution_time 还报超时？
PHP 的 max_execution_time 只控制脚本整体运行时长，而 phpMyAdmin 自己有一套独立的超时检查逻辑：$cfg['ExecTimeLimit']。它默认是 300 秒（5 分钟），且每执行一段 SQL 就手动校验一次，不依赖 PHP 底层计时器。
- 这个配置在
config.inc.php里，不是php.ini；路径通常是/usr/share/phpmyadmin/config.inc.php或 XAMPP 下的XAMPP\phpMyAdmin\config.inc.php - 直接加一行：
$cfg['ExecTimeLimit'] = 0;（设为 0 表示禁用） - 改完不用重启 Apache，但浏览器要清缓存或换无痕窗口，否则旧配置仍生效
max_allowed_packet 不够会导致“假性超时”
当你导入含大字段（如 TEXT、JSON、长 INSERT）的 SQL，MySQL 服务端会尝试把整条语句载入内存缓冲区。若语句长度超过 max_allowed_packet，MySQL 直接拒绝接收，phpMyAdmin 就会卡住、白屏或静默失败——看起来像超时，实际是连接被服务端单方面中断。
- 查当前值：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';" - 临时生效（仅当前会话）：
SET GLOBAL max_allowed_packet = 268435456;（即 256MB） - 永久生效：编辑
my.cnf或my.ini，在[mysqld]段下加：max_allowed_packet = 256M，然后重启mysql服务 - 注意：别写
100M这种值，部分旧版 MySQL 解析失败；用64M、128M、256M更稳妥
Web 服务器网关超时（504 Gateway Timeout）常被误认为 PHP 超时
PHP 脚本可能已经跑完了，但 Nginx/Apache 等网关等不到完整响应就主动断开，返回 504。这和 max_execution_time 完全无关，是反向代理层自己的限制。
- Nginx 用户：检查
location ~ \.php$块里的fastcgi_read_timeout，至少要比 PHP 的max_execution_time大 10–20 秒（例如 PHP 设 600，这里设 620） - Apache 用户：确认虚拟主机或主配置中
Timeout指令是否 ≥ 600 - 如果用了 Cloudflare，免费版有 100 秒硬性超时，无法绕过，必须直连或升级
真正容易被忽略的是：这些参数改完后，必须分别验证是否生效——phpinfo() 查 PHP 配置，SHOW VARIABLES 查 MySQL 配置，curl -I 或日志查 Web 层超时设置。缺一不可，漏一个就会白忙活。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
