navicat 不能还原 .psc 文件，因其是 percona xtrabackup 生成的物理备份（本质为含 innodb 页结构的 tar.gz），而 navicat 仅支持 .sql 等逻辑格式；必须用同版本 xtrabackup 执行解包、prepare 和 copy-back，navicat 仅可用于后续验证。
navicat 不能还原 .psc 文件——它根本不是 navicat 能处理的格式。 所有试图在 navicat 界面里点“还原备份”选 backup.psc 的操作，最终都会卡住、报错 unsupported file format 或静默失败。这不是权限问题、也不是版本太低，而是设计上就不支持。
为什么 Navicat 打不开 .psc 文件
.psc 文件不是 SQL 文本，也不是标准压缩包；它是 Percona XtraBackup 生成的物理备份归档（本质是 tar.gz，但含 InnoDB 页结构、日志、元数据等二进制内容）。Navicat 只认 .sql、.sql.gz、.sql.zip 这类逻辑导出格式，无法解析物理页或调用 xtrabackup 引擎。
- 双击
backup.psc→ 无响应或弹窗提示 “File is not a valid SQL dump” - 用 Navicat 的「导入向导」加载 → 日志出现
unexpected byte at position 0 - 强行重命名为
backup.sql.gz→ 解压后内容是二进制，MySQL 报错You have an error in your SQL syntax near 0x89
先确认 .psc 是不是纯 SQL 文本
有些用户误把 mysqldump 导出的 SQL 文件保存为 .psc 后缀——这种情况极少见，但值得花 10 秒验证：
- 用 VS Code / Notepad++ / vim 打开
backup.psc - 看开头几行：是否有
CREATE DATABASE、USE `xxx`;、大量INSERT INTO？ - 看有没有乱码（如
\x00\x00\x00、\x89PNG等二进制头） - 如果有 SQL 语句且无乱码 → 重命名为
backup.sql，再用 Navicat 的「运行 SQL 文件」导入 - 如果有乱码 → 它就是真正的物理备份，必须走
xtrabackup命令行流程
真正能还原 .psc 的只有 xtrabackup 命令行
Navicat 在这个过程里只配当“事后验证工具”，还原主体必须由 xtrabackup 完成。关键步骤和易错点如下：
- 解包：
tar -xzf backup.psc -C /restore/path/（部分版本需先用pxb_unpack） - prepare（不可跳过）：
xtrabackup --prepare --target-dir=/restore/path/；若备份加密，必须加--decrypt和--encrypt-key - 停 MySQL，清空原
datadir（如/var/lib/mysql），再 copy-back：xtrabackup --copy-back --target-dir=/restore/path/ - 改权限：
chown -R mysql:mysql /var/lib/mysql - 启动 MySQL 后，再用 Navicat 连接该实例查数据——这才是它该干的事
版本兼容性最容易被忽略：xtrabackup 8.0.x 生成的 .psc，必须用同主版本号（如 8.0.32）的 xtrabackup 还原；跨大版本（5.7 → 8.0）直接失败，且 prepare 阶段可能不报错但后续启动崩溃。
