导出时选GZIP但文件没压缩，是因为“格式”设为SQL和“压缩”选GZIP这两个开关必须同时启用；常见错误是只改格式未选压缩，导致下载的是未压缩的.sql文件。
导出时选GZIP但文件没压缩？检查导出页面的“格式”和“压缩”是否同时启用
phpmyadmin 默认导出是纯 sql 文本，选 gzip 仅表示「导出后用 gzip 压缩」，但这个动作依赖两个独立开关：一是导出格式设为 sql（不能选 csv 或 json），二是下方「压缩」下拉菜单必须手动选 gzip。常见错误是只改了格式没点压缩，结果下载的是未压缩的 .sql 文件。
实操要点：
- 进入数据库或表页 → 点「导出」标签页
- 「导出方法」选「自定义」（快速导出不支持压缩）
- 「格式」保持默认
SQL（其他格式如XML不支持 GZIP 压缩） - 滚动到底部，找到「压缩」选项 → 从下拉菜单选
GZIP - 确认「文件名」后缀是
.sql.gz（系统通常自动补全，但可手动检查）
导出大库失败或超时？调整 phpMyAdmin 和 PHP 的超时与内存限制
选 GZIP 后，phpMyAdmin 会先生成完整 SQL 再调用 gzencode() 压缩，这比直接输出文本更耗内存和时间。50MB 以上的库容易触发 Maximum execution time exceeded 或 Allowed memory size exhausted 错误。
临时解决办法（无需改服务器配置）：
- 在导出页面勾选「分隔符」→ 「将转储拆分为多个文件」，再设「每个文件最大大小」为 20M（避免单次处理过大）
- 取消勾选「包含创建数据库语句」和「添加 DROP TABLE」——减少 SQL 冗余内容，降低压缩前体积
- 若仍失败，改用命令行：
mysqldump -u user -p db_name | gzip > backup.sql.gz（更稳定，不受 PHP 限制）
导出的 .sql.gz 文件打不开？验证 GZIP 头部和解压工具兼容性
部分用户反馈双击 .sql.gz 文件提示「未知格式」，其实不是导出失败，而是本地解压工具不识别 GZIP 流式压缩（phpMyAdmin 用的是 gzencode()，非 tar.gz 封装）。这不是 bug，是格式差异。
立即学习“PHP免费学习笔记（深入）”；
正确解压方式：
- Linux/macOS：直接
gunzip backup.sql.gz（生成backup.sql） - Windows：用 7-Zip 或 WinRAR 打开，不要用系统自带解压器；或重命名为
backup.sql.gzip再试 - 验证是否有效：终端运行
file backup.sql.gz，应返回backup.sql.gz: gzip compressed data...
为什么导出的 GZIP 文件比预期大？SQL 导出本身不可压缩，GZIP 效果取决于数据重复度
GZIP 对纯文本压缩率高，但 SQL 导出里大量字段名、关键字（如 INSERT INTO、VALUES）重复极多，理论上压缩比应达 70%+。如果实际只有 10%~20%，大概率是导出时启用了「使用十六进制显示 BLOB」或「以 UTF-8 编码保存」，导致二进制字段被转成冗长的十六进制字符串，破坏了文本规律性。
优化建议：
- 导出前确认「以十六进制格式显示 BLOB」未勾选（除非真需要查看 BLOB 内容）
- 「编码」选
utf8mb4即可，避免选binary或latin1后再转码 - 若库含大量 JSON/TEXT 字段，且内容本身已压缩（如 base64 图片），GZIP 几乎无效——此时应跳过压缩，直接导出 .sql
真正影响 GZIP 效果的，从来不是 phpMyAdmin 设置，而是你导出的数据本身有没有可压缩的重复模式。
