phpmyadmin导入超长sql报504，根本原因是nginx的fastcgi_read_timeout超时（默认60秒），而非php脚本未完成；需在location ~ .php$块中同步调大fastcgi_read_timeout（如600）、client_max_body_size（如512m），并确认php的max_execution_time与mysql的max_allowed_packet均适配，否则仍会失败。
phpMyAdmin导入超长SQL报504，不是Nginx单方面问题
504错误本质是Nginx等不到PHP-FPM返回响应，而非PHP脚本没跑完。phpMyAdmin走的是FastCGI协议（fastcgi_pass），proxy_read_timeout这类参数完全无效，改了也白改。
真正起作用的是：fastcgi_read_timeout——它控制Nginx等待PHP-FPM响应的最长时间。默认60秒，导入大SQL时根本不够用。
- 必须在Nginx站点配置的
location ~ \.php$块内显式设置fastcgi_read_timeout，比如设为600（10分钟） -
client_max_body_size也要同步加大（如512m），否则还没到执行阶段，Nginx就在接收请求体时直接返回413 - 别在
http块或全局位置加这些指令——它们只对当前location生效
为什么调大max_execution_time后还是504
PHP层max_execution_time和Nginx层fastcgi_read_timeout是两套独立计时逻辑。前者控制PHP脚本最多运行多久，后者控制Nginx最多等PHP多久回包。哪怕PHP脚本还有5秒才跑完，只要Nginx的fastcgi_read_timeout先到期，就立刻甩出504。
- 推荐设置：PHP的
max_execution_time = 300，Nginx的fastcgi_read_timeout = 320（留20秒缓冲） - 如果用了PHP-FPM，还要检查
www.conf里有没有php_admin_value[max_execution_time]——它会强制覆盖php.ini的值 - Apache用户则要留意
Timeout指令，默认常为60秒，同样需同步调高
max_allowed_packet不足会导致白屏，不是超时
导入中途突然白屏，或报MySQL server has gone away，大概率不是超时，而是MySQL服务端主动断连。WordPress导出的SQL常含巨型INSERT语句，单条可能超10MB，而MySQL默认max_allowed_packet仅4MB（5.7）或64MB（8.0+）。
- 查当前值：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';" - 永久修改：编辑Windows下的
my.ini，在[mysqld]段加max_allowed_packet = 256M，然后重启MySQL服务 - 这个值必须 ≥ 你上传的单条INSERT语句长度，不是文件总大小——切片导入也得保证每片里的单条语句不越界
真正稳的方案：绕过phpMyAdmin直连MySQL
调参是权宜之计。phpMyAdmin本身把整个SQL读进PHP内存再解析执行，遇到含百万级INSERT的文件，OOM和超时几乎是必然的。命令行导入跳过Web层所有限制，才是生产环境首选。
- 基本命令：
mysql -u 用户名 -p 数据库名 - 如果SQL含
CREATE DATABASE或权限语句，先登录后执行：source C:/path/to/file.sql - 拆分大文件可用
split -b 100M big.sql part_（Linux/macOS），Windows下可用sql-split等工具
最易被忽略的一点：所有配置修改后，必须确认改的是实际生效的那个文件——用phpinfo()查Loaded Configuration File路径，而不是凭印象去改C:\xampp\php\php.ini。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
