phpmyadmin 不支持直接导入 .sql.gz 文件，因其导入功能不处理 gzip 解压；正确做法是用命令行 gunzipphpmyadmin 本身不支持直接导入
.sql.gz文件——你点“选择文件”后上传失败、没反应或报错，不是操作问题，是功能缺失。为什么 phpMyAdmin 界面里选不了 .gz 文件？
phpMyAdmin 的“导入”页只识别未压缩的
.sql（或.csv/.json），它不会自动解压。即使你手动改后缀为.sql，PHP 的$_FILES机制仍会把二进制 gzip 流当无效 SQL 解析，导致空白页或MySQL server has gone away错误。常见错误现象：
– 上传按钮灰掉 / 无法选择.gz文件
– 上传后进度条卡住，最终跳转到空的“导入结果”页
– 日志里出现upload_max_filesize exceeded，哪怕文件实际只有几 MB（因为 gzip 解压后远超限制）
- 根本原因：phpMyAdmin 导入流程依赖 PHP 的
move_uploaded_file()+ MySQL 客户端执行，不经过 shell 层，无法调用gunzip- 绕过方式只有两个：服务端预解压，或彻底绕开 phpMyAdmin 界面
- 别试“用 JS 前端解压再提交”，浏览器不支持读取原始 gzip header，且大文件会卡死
用命令行 mysql + gunzip 绕过所有限制
这是最稳、最快、兼容性最好的方案，适用于任何 Linux/macOS 服务器（Windows 可用 WSL）。它不走 PHP 上传流程，不受
upload_max_filesize、post_max_size或 phpMyAdmin 内存限制影响。假设你的压缩包叫
backup.sql.gz，数据库名是myapp：gunzip <p>说明：<br>– <code>gunzip 是流式解压，不生成临时 <code>.sql</code> 文件，省磁盘、省时间<br>– <code>|</code> 把解压后的内容直接喂给 <code>mysql</code> 客户端，全程内存处理<br>– 如果提示 <code>ERROR 2006 (HY000): MySQL server has gone away</code>，大概率是 <code>max_allowed_packet</code> 太小，加参数：<br><code>gunzip </code></code></p>
- 密码别写在命令里（会被历史记录泄露），用
-p让它交互式输入- 如果数据库有字符集要求（比如 utf8mb4），加上
--default-character-set=utf8mb4- 导入过程无进度条，但可以用
pv backup.sql.gz | gunzip | mysql ...（需先apt install pv）看实时流速如果只能用 phpMyAdmin，必须提前解压并拆分
当服务器没 SSH 权限、只能靠 Web 界面时，唯一办法是本地解压 + 拆分 + 分批上传。这不是加速，而是妥协。
使用场景：
– 共享主机（如 cPanel）不允许命令行访问
– 运维策略禁止外部连接 MySQL 端口
- 本地用
gunzip backup.sql.gz得到backup.sql- 用
split -l 5000 backup.sql backup_part_按行数切分（5000 行 ≈ 1–2 MB，避免超限）- 确保每个分片以
USE myapp;开头，或在 phpMyAdmin 里手动选中目标库再导入- phpMyAdmin 的“部分导入”功能（勾选 “Partial import”）仅对单个大文件内部跳过语句有效，不能替代拆分
真正容易被忽略的点：gzip 压缩率再高，解压后的 SQL 体积才是 MySQL 实际要处理的数据量。如果你的
.sql.gz是 20MB，解压后可能达 200MB，这时候光靠“换更大 upload_max_filesize”治标不治本——命令行管道才是直击本质的做法。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
