.nb3文件不能跨服务器直接还原，因其加密且绑定源环境；跨服迁移应使用SQL脚本导出导入或Navicat数据传输功能，后者最稳妥但不复制权限等服务器级对象。
Navicat 的 .nb3 备份文件不能直接跨服务器还原
navicat 自带的 backup 功能生成的 .nb3 文件是加密、平台相关且绑定源连接上下文的。它不是通用备份格式，无法在新服务器上双击或“导入”就生效——即使目标 mysql 实例版本、字符集完全一致，也会提示“备份文件无效”或“无法识别数据库对象”。这是最常被忽略的前提。
真正能跨服务器迁移的，只有 SQL 脚本（.sql）或通过数据传输工具完成。如果你手头只有 .nb3 文件，必须先在原环境还原出一个临时库，再导出为 SQL；或者用 Navicat 的“数据传输”功能直连两台服务器同步。
用“数据传输”功能直连新旧服务器同步
这是最稳妥、最接近“一键迁移”的方式，不依赖中间文件，全程在 Navicat 内完成：
- 确保新服务器已创建同名空数据库（编码、排序规则需与原库一致，否则中文可能乱码）
- 在 Navicat 左侧连接列表中，同时打开旧服务器和新服务器两个连接
- 右键旧服务器下的目标数据库 → 选择
数据传输→ 在弹窗中左侧选源库，右侧选新服务器上的空目标库 - 勾选
结构和数据，点击选项→ 确保删除目标表中已存在的记录和创建目标表均启用（避免主键冲突或缺失表） - 点击
开始，观察日志中每张表的传输状态；若某张大表卡住，可单独勾选该表重试
注意：数据传输 不复制用户权限、存储过程、事件等服务器级对象，只处理库内表结构与数据。如需这些，得额外导出 mysql 系统库相关语句或用命令行 mysqldump --routines --events。
用 Dump SQL File 导出再执行还原
适合对目标环境控制力强、需要审计 SQL 内容或做轻量修改的场景：
- 右键旧库 →
Dump SQL File→ 选Structure and Data（不要只选 Structure，否则没数据） - 保存为
.sql文件，**务必勾选添加 DROP TABLE IF EXISTS**，否则还原时会因表已存在报错 - 在新服务器上新建同名数据库（字符集建议显式指定，如
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;） - 右键新库 →
Execute SQL File→ 选刚导出的.sql文件 → 点Start
常见坑：.sql 文件默认不含 USE database_name;，如果文件里建表语句没带库名前缀，执行时必须先选中目标库；另外 MySQL 8.0+ 的认证插件（caching_sha2_password）可能导致 Navicat 连接失败，需提前在新服务器上把用户密码重置为 mysql_native_password 方式。
手动还原 .nb3 到新服务器的唯一可行路径
仅当无法访问原服务器、但手上有 .nb3 文件且必须抢救数据时才考虑。本质是“绕过 Navicat”，用底层机制还原：
- 在新服务器上安装与原环境**完全相同版本**的 MySQL（包括小版本号，如 8.0.33），并配置相同
innodb_file_per_table=ON和datadir路径 - 将
.nb3文件用 Navicat 在原环境还原到一个临时库，然后立即用mysqldump导出为 SQL —— 这是唯一合法提取方式 - 若原环境已不可用，
.nb3文件基本无法解包；网上流传的.nb3解密工具多为伪造或失效，且违反 Navicat 许可协议
所以别把 .nb3 当作跨服务器备份方案。它只适合同环境、同连接、快速回滚——比如开发库误删表后几秒内恢复。把它存进 NAS 或云盘，却指望半年后迁移到新云主机上直接点“还原”，注定失败。
