phpMyAdmin的“gzip压缩”对大库无效，因其在PHP内存中生成完整SQL再压缩，易致内存耗尽、超时或截断；应改用mysqldump | gzip管道实时压缩，配合--single-transaction等参数保障一致性与完整性。
phpMyAdmin 本身不支持直接导出 .gz 文件——点“压缩为 gzip”只是前端打包，实际仍先生成完整 SQL 再压缩，大库极易超时或内存溢出。真要省时间，必须绕过 phpMyAdmin 界面，用 mysqldump + gzip 管道操作。
为什么 phpMyAdmin 的 “gzip 压缩” 选项对大库无效
勾选“gzipped”后，phpMyAdmin 会尝试在 PHP 进程内存中拼完全部 SQL 再调用 gzencode()，导致：
- PHP 内存耗尽（
Fatal error: Allowed memory size exhausted） - 执行超时（
Maximum execution time of 300 seconds exceeded） - 导出文件中途截断但无报错（末尾搜不到
COMMIT就是证据） - 即使成功，压缩过程也拖慢整体耗时——它没利用多核，纯单线程
真正节省时间的 gzip 导出方案：命令行管道
用 mysqldump 直接吐出 SQL 流，交给 gzip 实时压缩，全程不落地、不占磁盘空间：
mysqldump -u root -p --single-transaction --routines --triggers --events your_db_name | gzip > your_db_name.sql.gz
关键参数说明：
立即学习“PHP免费学习笔记（深入）”；
-
--single-transaction：保证一致性，避免锁表（仅对 InnoDB 有效） -
--routines和--triggers：否则存储过程、触发器全丢 -
--events：漏掉事件调度器，定时任务就恢复不了 - 不要加
--skip-extended-insert：它会让每行数据独立INSERT，gzip 压缩率暴跌 60% 以上
比 gzip 更快的替代：用 pigz 多核压缩
如果服务器是多核（现代机器基本都是），pigz 能把压缩速度提 3–5 倍：
mysqldump -u root -p your_db_name | pigz > your_db_name.sql.gz
安装方式（Ubuntu/Debian）：
sudo apt install pigz
注意：pigz 不是默认预装，没装就报 command not found；CentOS/RHEL 用 yum install pigz 或 dnf install pigz。
导出后必须立刻验证，别信“下载完成”就万事大吉
管道压缩一旦中断，.sql.gz 文件就是损坏的，但文件大小看着正常。两步验证缺一不可：
- 检查完整性：
gzip -t your_db_name.sql.gz—— 返回空行才表示 OK - 抽样解压看头尾：
gunzip -c your_db_name.sql.gz | head -20和gunzip -c your_db_name.sql.gz | tail -20，确认有CREATE TABLE和COMMIT
真正耗时的不是压缩本身，而是错误重试和传输失败。跳过验证，后面传到远端才发现损坏，才是最浪费时间的操作。
