Navicat 不支持可控压缩,仅提供固定 level 6 的 gzip 压缩(.sql.gz),无法调节等级、更换算法或加密;真正自定义压缩需导出为纯 .sql 后用外部工具(如 7z/gzip/gpg)二次处理,并通过脚本串联实现定时备份+压缩加密。
Navicat 本身不支持压缩备份文件,只支持“导出为 .sql.gz”但不可控
navicat 的「导出向导」或「自动备份任务」里勾选 compression,实际只是调用内置 gzip(固定 level 6),输出为 .sql.gz 文件——它不是 zip,也不是带密码的压缩包,更无法调节压缩等级或换算法。你看到的“压缩”选项,本质是开关,不是配置项。
常见错误现象:以为勾了 Compression 就等于“压缩加密”,结果文件被第三方工具解不开、导入报错 ERROR 1064,或在旧版 Linux 上提示 invalid compressed data--format violated,其实是 Navicat 写入 gzip 流时省略了部分标准头信息导致的兼容性问题。
- 导出路径不能写成
backup.zip或backup.7z,Navicat 会强制覆盖为.sql或.sql.gz - 即使你指定
backup_20240727.sql.gz,Navicat 仍可能重命名为backup_20240727.sql(未压缩)或backup_20240727.sql.gz(固定 level 6 gzip) - mysqldump 命令行可自由控制
gzip -9或zstd -19,但 Navicat 界面完全不透出这些参数
真正能自定义压缩的唯一方式:导出为 .sql 后用命令行重压
绕过 Navicat 的压缩封装,把备份拆成两步:先让它生成干净的 .sql 文件,再用系统工具二次压缩。这样你才能控制算法、等级、密码和文件名格式。
实操建议:
- Navicat 备份设置中关闭
Compression,确保输出纯文本.sql - Windows 下用
7z.exe:支持 AES-256 加密 + 自定义字典大小,命令形如:7z a -pMyPass123 -mhe=on backup_20260727.sql.7z backup_20260727.sql
- macOS/Linux 下推荐
gpg --symmetric+gzip -9组合(避免 zip -e 的交互式密码输入):gzip -9 backup_20260727.sql && gpg --symmetric --cipher-algo AES256 backup_20260727.sql.gz
- 别用
zip -e直接加密,它依赖终端交互,无法嵌入定时脚本
自动备份+压缩必须用外部脚本串联,Navicat 没有“运行后回调”
Navicat 的「计划任务」不提供 post-backup hook,它的「运行 Windows 应用程序」动作只能启动一个进程,不能等备份完成再执行下一步。所以不能分开配两个任务(备份 → 压缩),必须把整个流程打包进单个脚本里,再让 Navicat 调用该脚本。
关键点:
- 脚本开头要加延迟或文件存在检测,避免压缩空文件(
if exist backup_*.sql) - 时间戳命名必须统一:Navicat 导出用
%date:~-4,4%%date:~-7,2%%date:~-10,2%,脚本里也得用同样逻辑,否则找不到源文件 - Linux/macOS 脚本需设
#!/bin/bash并赋予+x权限;Windows 批处理注意路径含空格时要用双引号包裹 - Navicat 调用脚本时,务必勾选「以管理员权限运行」(尤其写入系统盘或需要访问网络驱动器时)
压缩等级选 1–3 就够了,别盲目追求 -9
SQL 文本可压缩性有限,gzip -1 和 -9 的体积差通常不到 8%,但耗时可能差 3–5 倍。Navicat 卡在「Writing data」阶段,大概率不是磁盘慢,而是 CPU 被 gzip -9 占满又无法释放线程。
实测对比(500MB 数据库):
-
gzip -1:耗时 23s,输出 182MB -
gzip -6(Navicat 默认):耗时 58s,输出 176MB -
gzip -9:耗时 142s,输出 174MB
真正影响体验的是「同步阻塞式压缩」:Navicat 必须等整个 .sql 写完才开始压,期间界面冻结。所以与其调等级,不如关压缩 + 改用 zstd -3(快 3 倍,压缩率接近 gzip -6)。











