Navicat 16 不支持对 .sql 或 .ncb 备份文件进行 AES 高强度加密；所谓“加密备份”仅加密内存缓存并生成私有 .sql.enc 格式，依赖同版本、同用户、已设主密码的封闭环境，不可审计、不可跨平台解密，合规场景应采用 mysqldump + openssl 等外部标准加密方案。
Navicat 16 不支持对备份文件（如 .sql 或 .ncb）进行 AES 高强度加密。
它所谓的“加密备份”功能，本质是把连接密码用固定密钥（libcckeylibcckey）AES-256-CBC 加密后存进配置，和备份文件本身无关。导出的 .sql 是纯文本，.ncb 格式未公开、不可验证、不兼容跨环境解密，也不满足等保/密评对加密算法可审计、密钥可管理的要求。
Navicat 16 备份界面里的“加密”选项到底在加密什么
- 界面中勾选“加密备份”，实际只对备份过程中的内存缓存数据流做一次 AES-256 加密，然后写入磁盘为
.sql.enc文件 - 这个
.sql.enc不是标准格式：无文件头标识、无盐值、无密钥派生，依赖 Navicat 自己的私有解密上下文 - 解密必须满足三个硬条件：
- 同版本 Navicat（比如 v16.3.1 备份 → v16.3.1 还原）
- 同一操作系统 + 同一用户账户（Windows 上管理员 vs 普通用户会失败）
- 主密码（Master Password）已设置且未重置（否则密钥链断裂）
- 若环境稍有偏差，解密时直接报错
Invalid encrypted file format，没有中间态或调试提示
为什么 mysqldump + openssl 是更可靠的选择
Navicat 的备份加密卡顿、不可控、不可验证；而命令行组合可明确控制算法、密钥、填充、IV，并能验证解密结果：
- 使用
mysqldump导出（跳过锁表、保证一致性）：mysqldump --single-transaction --skip-lock-tables -h host -u user -p database > backup.sql
- 再用
opensslAES-256-CBC 加密（密钥由口令派生，安全可控）：openssl aes-256-cbc -salt -pbkdf2 -iter 100000 -in backup.sql -out backup.sql.enc
- 解密验证（输同一口令即可）：
openssl aes-256-cbc -d -pbkdf2 -iter 100000 -in backup.sql.enc | head -20
这样生成的 .sql.enc 是标准 OpenSSL 格式，任何支持 PKCS#5 的工具都能解，密钥不硬编码、不绑定用户环境。
如果非要用 Navicat 导出并手动加密，该怎么做
绕过 GUI 的“加密备份”开关，走三步法（导出 → 加密 → 归档），才能真正落地 AES 强度：
- 导出时不勾选“加密备份”，只勾选“压缩备份文件”（避免 Navicat 自带 zlib 压缩干扰加密流）
- 用外部工具加密，例如：
-
7z a -p -mhe=on backup.7z backup.sql（AES-256 + 文件头加密） -
gpg --cipher-algo AES256 --symmetric backup.sql（PGP 标准，密钥管理更灵活）
-
关键点在于：Navicat 从不暴露加密密钥，也不允许你指定 IV 或迭代次数；所有“可控加密”都必须脱离它的 GUI 流程。
真正需要 AES 高强度加密时，Navicat 的内置选项只是幻觉。它适合快速本地备份，不适合合规场景。加密动作本身不难，难的是密钥生命周期管理和解密可重复性——这两点，Navicat 全部交给了黑盒。
