要解决phpMyAdmin执行长SQL超时问题，必须同步调整Nginx的fastcgi_read_timeout、PHP-FPM的request_terminate_timeout及phpMyAdmin的$cfg['ExecTimeLimit']，三者缺一不可；还需关注MySQL的max_allowed_packet等限制。
直接改三个地方就能解决：Nginx 的 fastcgi_read_timeout、PHP-FPM 的 request_terminate_timeout、phpMyAdmin 自身的 $cfg['ExecTimeLimit']。漏掉任意一个，都可能卡在 30 秒或 60 秒就报 504/502。
nginx fastcgi_read_timeout 和 send_timeout 必须调高
phpMyAdmin 执行长 SQL 时，Nginx 默认只等 60 秒（fastcgi_read_timeout），超时就断开连接，返回 504 Gateway Timeout。这不是 PHP 没响应，是 Nginx 主动砍掉了。
修改 /usr/local/nginx/conf/nginx.conf（或对应 server/location 块）：
fastcgi_connect_timeout 600; fastcgi_send_timeout 600; fastcgi_read_timeout 600;
注意：fastcgi_read_timeout 是最关键的——它控制 Nginx 等待 PHP-FPM 返回响应的最长时间。如果 SQL 跑了 120 秒，但这里还是 300，Nginx 就会提前终止。
立即学习“PHP免费学习笔记（深入）”；
改完必须 reload Nginx：nginx -s reload，否则不生效。
php-fpm request_terminate_timeout 要设为 0 或足够大
即使 Nginx 等得够久，PHP-FPM 自己也会杀进程。日志里看到 execution timed out (125.496217sec), terminating 就是它干的。
编辑 /usr/local/php/etc/php-fpm.conf（或 pool 配置文件），找到并修改：
request_terminate_timeout = 0
0 表示不限制；若不想完全放开，可设为 600（秒）。别用 max_execution_time ——那是 PHP 脚本层限制，对 phpMyAdmin 的 SQL 执行不起作用（它走的是 FastCGI 请求生命周期）。
改完必须重启：systemctl restart php-fpm 或 kill -USR2 `cat /usr/local/php/var/run/php-fpm.pid`。
phpMyAdmin 的 $cfg['ExecTimeLimit'] 控制界面级超时
这个参数管的是 phpMyAdmin 前端“执行按钮”点击后，后台等待 SQL 完成的最大秒数。默认是 300（5 分钟），但如果你改了上面两个，它反而会先一步中断。
编辑 phpMyAdmin 的配置文件 config.inc.php（不是 config.default.php），加一行：
$cfg['ExecTimeLimit'] = 0;
0 表示禁用前端超时检测；若想留个兜底，可设为 1200（20 分钟）。这个值不能超过 request_terminate_timeout，否则没意义。
注意：有些旧版 phpMyAdmin 用的是 $cfg['max_exec_time']，请 grep 确认实际键名。
别忘了 MySQL 层的 max_allowed_packet 和 wait_timeout
超时不是唯一瓶颈。如果 SQL 文件本身很大（比如 200MB 导入），max_allowed_packet 太小会导致直接截断，报错类似 Packets larger than max_allowed_packet are not allowed。
在 MySQL 配置（my.cnf 的 [mysqld] 段）中加：
max_allowed_packet = 256M
同时检查 wait_timeout（默认 28800 秒 = 8 小时），一般不用动；但若你在 phpMyAdmin 里手动开启事务后发呆太久，它可能自动断连。
改完要重启 MySQL：systemctl restart mysqld。
真正容易被忽略的是：这四个层级（Nginx → PHP-FPM → phpMyAdmin → MySQL）的超时和包大小限制，任何一个卡住，都会表现为“执行 SQL 卡死”或“502/504”，但错误日志分散在不同地方。查问题前，先确认你改的是哪一层的日志输出源。
