因为504是Nginx的fastcgi_read_timeout触发（默认60秒），非proxy_read_timeout；必须同步调大client_max_body_size、fastcgi_read_timeout、fastcgi_send_timeout，以及PHP的upload_max_filesize、post_max_size、max_execution_time、memory_limit，并检查phpMyAdmin的ExecTimeLimit和MySQL的max_allowed_packet。
为什么改了 upload_max_filesize 还是 504？
因为 phpMyAdmin 走的是 FastCGI（不是 proxy），proxy_read_timeout 完全无效。真正卡住你的是 Nginx 的 fastcgi_read_timeout —— 它默认只有 60 秒，而大 SQL 解析+执行常需数分钟。
常见错误日志：upstream timed out (110: Connection timed out) while reading upstream，上游地址其实是 127.0.0.1:9000（PHP-FPM），不是后端 HTTP 服务。
必须同步调整以下三项：
-
client_max_body_size：加在location /phpmyadmin块里，值要大于你要传的 SQL 文件（如512m） -
fastcgi_read_timeout：核心项，设为预期最长执行时间（如600） -
fastcgi_send_timeout：导出大结果集时也可能触发，建议同步设高（如600）
PHP 层面哪些 php.ini 项必须改？
只改 upload_max_filesize 是不够的——它只是上传环节的一环。整个链路中，PHP 自己也会中途放弃。
立即学习“PHP免费学习笔记（深入）”；
确认并修改以下四个值（都在你实际生效的 php.ini 中）：
-
upload_max_filesize：比如设为512M -
post_max_size：必须 ≥upload_max_filesize，建议设为512M或1G -
max_execution_time：默认 30 秒，大 SQL 导入常超时，建议设为600或0（不限制） -
memory_limit：phpMyAdmin 会把整个 SQL 文件读进内存分段执行，128M很容易 OOM，建议512M起
怎么找对那个 php.ini？在 phpMyAdmin 目录放个 info.php（内容 <?php phpinfo(); ?>），访问后搜 Loaded Configuration File。
phpMyAdmin 自身还有两道关卡
即使 Nginx 和 PHP 都放行了，phpMyAdmin 的内部限制仍可能中断导入。
打开 config.inc.php，检查或添加：
-
$cfg['ExecTimeLimit'] = 0;：禁用其内置执行时限（注意：这不能绕过 PHP 的max_execution_time） -
$cfg['UploadDir'] = 'upload';和$cfg['SaveDir'] = 'save';：启用服务器端文件导入模式，把 SQL 文件先用 FTP 传到upload/目录，再从下拉框选——完全绕过表单上传流程
启用后需在 phpMyAdmin 根目录手动建好 upload 和 save 两个空目录，并确保 Web 用户有读写权限（如 chown www-data:www-data upload）。
MySQL 层还可能报错：max_allowed_packet
即使上传和执行都成功，遇到含百万级 INSERT 的 SQL，MySQL 服务端可能拒绝接收单条过长语句，报错类似 Packets larger than max_allowed_packet bytes are not allowed。
修改 MySQL 配置（my.cnf 或 my.ini）：
- 在
[mysqld]段下加：max_allowed_packet = 512M - 同时检查客户端配置（
[mysql]段），也建议设为相同值 - 改完重启 MySQL：
sudo systemctl restart mysql
这个值必须覆盖你 SQL 文件里最长的一行（比如一条超长的 INSERT ... VALUES (...)），不是文件总大小。
真正超大 SQL（>200MB）别硬扛——mysql 命令行直导最稳：mysql -u root -p database_name < /path/to/file.sql。它不走 HTTP、不进 PHP 内存、不受任何上传或脚本超时限制，唯一瓶颈是磁盘 IO 和 MySQL 自身配置。
