phpMyAdmin导出卡在“请等待”主因是PHP执行超时，需调高max_execution_time和phpMyAdmin的ExecTimeLimit；其次检查Nginx的proxy_read_timeout、CDN超时、禁用gzip、确认session.save_path权限及磁盘空间。
phpMyAdmin导出卡在“请等待”：先看 PHP 脚本执行是否超时
绝大多数情况，卡住不是界面问题，而是 max_execution_time 到了，php 直接中止脚本但没返回错误——浏览器就一直等。默认值通常为 30 秒，导出大表（比如百万行以上）或启用了压缩（gzip）、结构+数据全选、触发视图/存储过程解析时，很容易超。
- 检查当前值：
phpinfo()或运行echo ini_get('max_execution_time'); - 临时调高（仅限导出）：在 phpMyAdmin 根目录的
config.inc.php里加一行：$cfg['ExecTimeLimit'] = 300;（单位秒，这个是 phpMyAdmin 自己用的，优先级高于max_execution_time） - 真正生效还得改 PHP 配置：在
php.ini中设max_execution_time = 300，改完必须重启 PHP-FPM（不是只 reload Nginx） - 注意：设为
0表示不限制，但不推荐线上长期使用，容易被慢查询拖垮进程
Nginx 返回 504 Gateway Timeout？查 proxy_read_timeout
即使 PHP 没超时，Nginx 作为反向代理也可能先放弃等待。典型表现是卡几秒后直接弹出 504 页面，或者控制台看到 upstream timed out (110: Connection timed out) 错误。
-
proxy_read_timeout是关键：它控制 Nginx 等待上游（PHP-FPM）返回响应体的最大时间，默认常为 60 秒 - 需同步调高
proxy_connect_timeout和proxy_send_timeout，但重点是proxy_read_timeout，建议设为略大于 PHP 的max_execution_time（例如 360） - 配置位置在 Nginx 的 server 或 location 块里，不是全局 http 块；改完必须
nginx -t && nginx -s reload - 别漏掉：如果用了 Cloudflare 或其他 CDN，它们也有独立超时设置（如 Cloudflare 的「Origin Response Timeout」），同样要检查
导出大库时内存爆了？关掉 gzip 和禁用“保存到服务器”
phpMyAdmin 默认启用 gzip 压缩导出文件，对大库来说，PHP 进程会先把整个 SQL 缓存在内存里再压缩——极易触发 memory_limit 限制，导致 500 错误或静默失败，页面卡在“请等待”不动。
- 导出前，在 phpMyAdmin 导出页底部取消勾选
gzipped（即禁用 gzip） - 避免勾选
Save on server（保存到服务器磁盘），它会强制生成临时文件并做额外 I/O，增加失败概率 - 确认
memory_limit至少 256M（导出千万级数据建议 512M），改完同样要重启 PHP-FPM - 更稳妥做法：改用命令行导出，
mysqldump不走 PHP 内存缓冲，也绕过所有 Web 层超时
为什么改了所有超时还是卡？检查 session.save_path 权限和磁盘空间
很少人想到，phpMyAdmin 卡在“请等待”，有时根本不是超时，而是 session 写入失败——比如 session.save_path 目录不可写，或磁盘已满。PHP 无法保存导出任务状态，前端就永远收不到进度回调。
- 查日志：看 PHP 错误日志里有没有
Failed to write session data或Permission denied - 确认
session.save_path目录存在、属主是 PHP-FPM 运行用户（如www-data或nginx），且有写权限 - 用
df -h检查/tmp（session 默认路径）或自定义路径所在分区剩余空间 - 临时验证：在
config.inc.php加$cfg['TempDir'] = '/var/tmp/phpmyadmin';并确保该目录可写，能快速隔离问题
真正麻烦的是多个环节叠加超时：PHP 执行快到了但 Nginx 先断，或者 session 写失败后前端反复重试又撞上新超时。得逐层验证，不能只盯一个配置。
立即学习“PHP免费学习笔记（深入）”；
