phpMyAdmin 不支持直接导入 .sql.gz 文件，因其导入功能不处理 gzip 解压；正确做法是用命令行 gunzip < backup.sql.gz | mysql -u root -p myapp 流式导入。
phpmyadmin 本身不支持直接导入 .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：
立即学习“PHP免费学习笔记（深入）”；
gunzip < backup.sql.gz | mysql -u root -p myapp
说明：
– gunzip < backup.sql.gz 是流式解压，不生成临时 .sql 文件，省磁盘、省时间
– | 把解压后的内容直接喂给 mysql 客户端，全程内存处理
– 如果提示 ERROR 2006 (HY000): MySQL server has gone away，大概率是 max_allowed_packet 太小，加参数：gunzip < backup.sql.gz | mysql -u root -p --max-allowed-packet=512M myapp
- 密码别写在命令里（会被历史记录泄露），用
-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”治标不治本——命令行管道才是直击本质的做法。
