Navicat 16不支持直接还原加密的.sql文件，必须先在外部解密为合法SQL文本，再通过“运行SQL文件”导入；若误将.psc格式当作加密.sql，会导致还原失败或数据丢失。
Navicat 16 不支持直接还原加密的 .sql 文件
Navicat 16 本身没有“解密 SQL 文件”的能力——它只执行 SQL 语句，不处理文件级加密。如果你手里的 .sql 文件是人为用 AES、Base64、ZIP 密码或自定义脚本加密过的（比如用 OpenSSL 加密、7-Zip 设密码压缩后改名成 backup.sql），Navicat 会直接报错 ERROR 1064 (42000): You have an error in your SQL syntax，因为开头根本不是合法 SQL（而是乱码或二进制头）。
必须先在外部完成解密，再交给 Navicat 执行。常见错误现象包括：点击“开始”后进度条不动、几秒就失败、日志里出现大量不可见字符或 unexpected token 类提示。
怎么判断你的 .sql 文件是否被加密？
用文本编辑器（如 VS Code、Notepad++）直接打开该文件，观察前 20 行：
- 正常 mysqldump 导出的
.sql文件开头一定是-- MySQL dump或CREATE DATABASE/SET NAMES等可读 SQL 语句 - 如果看到
U2FsdGVkX1...（Base64 特征）、PK\x03\x04（ZIP 头）、\x89PNG（PNG 头，说明被当图片伪装）、或全是乱码/空格/控制字符，那就是被加密或封装过了 - 文件大小异常小（如 1KB）但声称含“全库数据”，大概率是密文占位；反之若 >100MB 却导入瞬间失败，也可能是解密后内容损坏
解密后导入 Navicat 的关键操作点
解密只是第一步，解出来的 .sql 文件仍需满足 Navicat 运行 SQL 文件的基本前提：
- 目标数据库必须已存在（Navicat 不会自动建库），且推荐为空库——否则
DROP TABLE IF EXISTS可能失败，或INSERT因主键冲突中断 - 检查解密后文件是否含
CREATE DATABASE；如果含，而目标连接下已有同名库，会卡在ERROR 1007: Can't create database 'xxx'; database exists - 确认 Navicat 连接属性中的「字符集」设为
utf8mb4，尤其当原库含 emoji 或中文时；否则解密后执行到INSERT会报ERROR 1366 - 大文件（>50MB）建议调高「最大执行时间」：工具 → 选项 → SQL 编辑器 → 把“最大执行时间(秒)”改为
3600，并取消勾选“限制返回行数”
特别注意：.psc 文件不是加密的 .sql
别把 .psc 和“加密 .sql”混为一谈。.psc 是 Navicat 自有备份格式，本质是加密压缩包，不能通过解密得到标准 SQL；它必须用同版本 Navicat 先还原到临时库，再右键该库 →「转储 SQL 文件」导出为真实 .sql。任何声称“一键解密 .psc 为 SQL”的工具都不可信——实测结果要么报错，要么丢表、丢索引、丢外键约束。
