.nb3文件是Navicat 12+专用加密格式，非标准SQL或压缩包，无法直接双击打开或用mysql命令导入。
nb3文件是Navicat 12+的加密专有格式，不是通用SQL或压缩包
你双击.nb3文件打不开、用mysql -u root 报error 1064、用7-zip解压失败——这些都不是操作错误，而是根本没对上格式。.nb3本质是aes-256-cbc加密容器，内含数据库快照+元数据+版本签名，密钥由navicat运行时动态派生（基于本地license缓存或在线验证），不随文件存储。旧版本（如navicat 11）压根没有解密逻辑和私有解析库libnavicatbackup.so，自然无法识别。
版本主号必须严格匹配，16.0.x和16.3.x之间也可能失败
Navicat官方明确要求还原端版本主版本号需与备份生成时一致。比如用Navicat 16.0.18备份的.nb3，不能在16.3.5里还原——即便都是v16。这是因为：
- 不同小版本的
libnavicatbackup.dll可能含定制OpenSSL补丁或反调试校验逻辑 - Windows版.nb3嵌入COM接口指针序列化对象，macOS版用CFPropertyList二进制编码，Linux版依赖glibc malloc arena快照，三者互不兼容
- 错误提示常为
Invalid pointer operation或Unknown Internal Error (A70529120825)，而非“版本不支持”这类友好提示
字符集/权限/存储引擎不匹配会导致还原中途失败
即使版本正确，还原仍可能卡在建表或视图创建阶段。常见触发点：
- 目标库字符集不是
utf8mb4（尤其原库含emoji或四字节UTF-8字符） - MySQL未开启
log_bin_trust_function_creators=1，导致函数/视图创建被拒绝 - 还原账户缺少
CREATE ROUTINE、ALTER ROUTINE或EXECUTE权限 - 备份中表使用
ARCHIVE引擎，但目标MySQL未启用该插件
此时Navicat通常只报“还原失败”，不会指出具体哪张表、哪个SQL语句出错，需打开日志或改用导出SQL再手动执行排查。
唯一可靠路径：用同主版本Navicat导出SQL再导入
当版本不匹配或还原报错时，别硬试“还原备份”按钮。直接走迂回路线更可控：
- 在能打开.nb3的高版本Navicat（如16.0.18）中，右键.nb3文件 → “导出SQL文件”
- 导出时勾选“包含创建数据库语句”，并确认目标库名与SQL中
USE `xxx`一致 - 将生成的
.sql文件用低版本Navicat或命令行mysql -u root -p database_name 导入
注意：导出SQL会丢失.nb3里的增量备份链、时间点恢复能力，且大库导出可能耗时——但这是绕过版本锁和加密壁垒最稳的方式。
