504 Gateway Timeout是Nginx等反向代理等待后端响应超时所致，需同步调大proxy_read_timeout、fastcgi_read_timeout、PHP-FPM的request_terminate_timeout、phpMyAdmin的ExecTimeLimit，并优化MySQL导出逻辑及架构。
504 gateway timeout 不是 phpmyadmin 卡住，也不是 mysql 挂了，而是 nginx（或其他反向代理）在等待响应时主动断开连接——导出大表时后端还没返回完整响应，它就放弃了。
proxy_read_timeout 必须调大，但别只改它
Nginx 默认 proxy_read_timeout 是 60 秒，而导出百万行数据常需 3–10 分钟。必须在 location ~ \.php$ 块里显式设大，例如：
proxy_read_timeout 600;
但光改这一项不够，因为：
-
proxy_connect_timeout和proxy_send_timeout虽然影响较小，但如果后端启动慢或传输卡顿，也会触发 504 - 云负载均衡（如阿里云 SLB、AWS ALB）有独立空闲超时，默认常为 60–300 秒，必须同步调整，否则 Nginx 改了也白搭
- 若用了
fastcgi_pass（常见于 PHP-FPM 场景），还要检查fastcgi_read_timeout，它优先级高于proxy_read_timeout，建议设为比 PHP 执行时间大 20 秒
PHP-FPM 的 request_terminate_timeout 会覆盖 Nginx 设置
即使 Nginx 等 600 秒，PHP-FPM 默认 request_terminate_timeout = 30（秒）仍会在 30 秒后强行 kill 进程，导致 Nginx 最终收不到响应而报 504。
检查你的 www.conf（路径类似 /etc/php/8.3/fpm/pool.d/www.conf），确认：
立即学习“PHP免费学习笔记（深入）”；
-
request_terminate_timeout已取消注释，设为600或0（禁用） - 没有被
php_admin_value[max_execution_time]之类配置覆盖 - 改完必须执行
sudo systemctl restart php8.3-fpm
phpMyAdmin 自身的 $cfg['ExecTimeLimit'] 是软限制
这个值只控制 phpMyAdmin 内部用 set_time_limit() 设的脚本运行上限，默认 300 秒。它不绕过 PHP 或 Nginx 层级的硬限制。
编辑 config.inc.php，添加或修改：
$cfg['ExecTimeLimit'] = 0;
注意：0 表示不限制；写成 false 或空字符串无效，phpMyAdmin 只认整数。
该设置仅对导入、导出、搜索等 phpMyAdmin 功能生效，不影响其他 PHP 脚本。
真正吃 CPU 和时间的是 mysqld，不是 phpMyAdmin
phpMyAdmin 导出本质是拼 SQL + 调用 MySQL 客户端逻辑，真正扫描、序列化、压缩数据的是 mysqld 进程。导出全表或未加 WHERE 条件时，CPU 飙升和耗时长都源于此。
实操建议：
- 导出前加条件：避免
SELECT * FROM huge_table，用WHERE created_at 限定范围 - 禁用「压缩」选项：gzip/zipped 在 PHP 层做极易超时，导出纯 SQL 后本地压缩更稳
- 超 100 万行，直接换
mysqldump命令行：mysqldump --single-transaction --no-create-info db_name table_name > data.sql - 用
pt-archiver分批导出，配合--limit 10000 --sleep 0.1控制压力
最易被忽略的一点：504 看似是超时问题，实则是架构误用信号——把长耗时任务塞进 Web 请求生命周期里，既压垮 Worker 进程，又掩盖真实性能瓶颈（如缺失索引、buffer_pool_size 过小）。真要稳定导出，得切到异步任务队列 + 临时文件直链下载模式。
