504是Nginx等网关层主动返回的超时错误，非phpMyAdmin自身产生；根本原因是fastcgi_read_timeout内未收全PHP-FPM响应，常见于SHOW TABLE STATUS元数据扫描耗时过长，需同步调大PHP的max_execution_time、memory_limit及Nginx的fastcgi_read_timeout，并优先使用mysqldump命令行导出大库。
504不是phpMyAdmin报的，是Nginx等网关主动断开的
phpMyAdmin本身不会返回504。它只是一个PHP脚本，运行在Web服务器（如Nginx）后面。当你点击“导出”，浏览器发请求 → Nginx接收并转发给PHP-FPM → PHP执行mysqldump逻辑、拼SQL、输出响应。如果PHP处理时间太长，Nginx在fastcgi_read_timeout时间内没收到完整响应，就会自己返回504。
常见错误日志里有upstream timed out (110: Connection timed out) while reading upstream，这里的“upstream”指的就是127.0.0.1:9000（PHP-FPM），不是MySQL，也不是其他后端服务。
- 别改
proxy_read_timeout——phpMyAdmin走的是fastcgi_pass，不是proxy_pass，这个参数完全不生效 -
client_max_body_size只影响上传（导入时才用），导出时不起作用 - 就算PHP脚本已跑完，只要响应体太大或分块慢，Nginx仍可能因
fastcgi_read_timeout未收全而504
真正卡住的地方：SHOW TABLE STATUS + 大表元数据扫描
导出前，phpMyAdmin默认会执行SHOW TABLE STATUS FROM `db_name`来获取每张表的行数、大小、引擎等信息，用于生成进度提示和统计摘要。这张语句在表多（>200）、单表大（>1GB）、InnoDB未缓存元数据时，可能耗时几十秒甚至更久——而这段时间内，PHP还没开始真正导出数据，Nginx已在倒计时。
- 这个查询无法通过“自定义导出”界面关闭，必须改代码或禁用表状态获取
- MySQL 8.0+ 的
information_schema访问变慢，尤其当innodb_stats_on_metadata=ON（默认）时，每次查TABLE_STATUS都会触发统计更新 - 解决办法之一：手动注释掉
libraries/database_interface.lib.php中调用SHOW TABLE STATUS的循环，替换为轻量占位数组
$cfg['ExecTimeLimit'] = 0 不等于不超时
很多人在config.inc.php里加了$cfg['ExecTimeLimit'] = 0;，以为就万事大吉。其实这只是告诉phpMyAdmin“别用set_time_limit()限制自己内部逻辑”，它**不解除PHP本身的max_execution_time，也不影响Nginx的fastcgi_read_timeout**。
立即学习“PHP免费学习笔记（深入）”；
- 必须同步改三处：
php.ini里的max_execution_time（建议300–600）、memory_limit（至少512M）、以及Nginx的fastcgi_read_timeout（建议≥600） - 若用PHP-FPM，还要检查
www.conf里有没有php_admin_value[max_execution_time]，它会强制覆盖php.ini - Cloudflare等CDN层也有硬性超时（免费版100秒），即使后端全调通，CDN也会在100秒后切504
更稳的替代方案：绕过Web层直接用命令行
对大于50MB或含千万级数据的库，phpMyAdmin导出本质是反模式：所有数据经PHP内存组装、再经HTTP流式吐出，中间任何一环（网络抖动、PHP GC、Nginx缓冲区）都可能中断，且失败后无法续传。
- 用
mysqldump直连导出：mysqldump -u root -p --single-transaction --routines --triggers db_name > dump.sql - 导出压缩包省空间：
mysqldump ... | gzip > dump.sql.gz - 若必须用phpMyAdmin生成的SQL做兼容性适配（比如含
utf8mb4_0900_ai_ci），建议先用命令行导出，再用sed批量替换排序规则，比在Web界面上反复试错快得多
