Navicat 15 不支持数据镜像，其“还原备份”仅为一次性结构+数据覆盖；.psc 文件跨版本还原需源目标MySQL版本兼容且目标≥源版本，.sql文件更适配但须注意权限、字符集、DEFINER及大文件执行方式。
Navicat 15 的“还原备份”不等于数据镜像
Navicat 本身没有「数据镜像」功能，所谓“不同环境间的数据镜像还原”，实际是用备份文件（.psc 或 .sql）在目标环境执行一次性的结构+数据覆盖。它不具备持续同步、增量拉取、冲突检测等镜像能力。如果你期待的是类似 MySQL 主从复制或第三方工具（如 SymmetricDS、Debezium）的效果，Navicat 无法满足。
用 .psc 文件跨环境还原的实操要点
.psc 是 Navicat 自有格式备份，依赖客户端解析，还原时会严格校验源库版本兼容性。MySQL 8.0.27 备份的 .psc 在 MySQL 5.7 环境中大概率失败，报错类似 Unsupported version: 80027。
- 确认目标 MySQL 版本 ≥ 源库版本（例如源为 8.0.27，目标至少为 8.0.27 或更高小版本）
- 还原前手动检查目标库的
sql_mode，尤其注意是否启用了STRICT_TRANS_TABLES—— 若源库未启用而目标启用了，可能因字段默认值缺失导致还原中断 - 如果源库使用了 MySQL 8.0 新特性（如隐藏索引、角色管理语句），
.psc还原会跳过这些对象，不会报错但也不生效 - 还原操作本质是先删表再重建，不是 patch 式更新；若目标库已有同名表且含外键约束，需提前禁用：
SET FOREIGN_KEY_CHECKS = 0;
用 .sql 文件还原更可控，但要注意编码和权限
比起 .psc，导出为 .sql 文件（右键数据库 → 转储 SQL 文件）对跨环境适配性更强，但容易在以下环节翻车：
- 导出时勾选
包含创建数据库语句：若目标环境不允许CREATE DATABASE权限（比如只给了dbuser@localhost对某个库的SELECT,INSERT,UPDATE,DELETE），还原会卡在第一行CREATE DATABASE `xxx`报错Access denied for user - 字符集不一致：源库是
utf8mb4_0900_ai_ci，目标库默认是utf8mb4_general_ci，虽能还原，但后续排序行为可能异常 - SQL 文件里含
DEFINER = 'admin'@'%'的视图或存储过程：目标环境无该用户时，还原会跳过这些对象，且不提示警告 - 大文件（>100MB）直接用 Navicat 的
运行 SQL 文件容易卡死或内存溢出；建议改用命令行：mysql -h host -u user -p database_name
真正接近“镜像效果”的折中做法
如果只是想让测试/预发环境定期拉取生产库最新快照，又不想写脚本，可以组合使用 Navicat 自动化 + 手动干预：
- 在生产环境用定时任务生成
.sql（非.psc），并关闭包含创建数据库语句，只保留USE database_name和建表/插入语句 - 把该
.sql文件通过共享目录或 rsync 同步到测试服务器 - 在测试环境 Navicat 中，右键目标数据库 →
运行 SQL 文件，勾选停止于错误—— 这样遇到主键冲突或唯一键重复时能及时中断，避免脏数据扩散 - 关键表（如配置表、字典表）还原前加一步人工核对：
SELECT COUNT(*) FROM t_config;和源库比对，防止误操作覆盖
最常被忽略的一点：Navicat 的还原操作不会自动清理目标库中源库不存在的表。如果你希望“完全镜像”，必须手动 DROP TABLE 多余表，或者先清空目标库再还原 —— 但后者意味着你要确保所有依赖关系（如其他库的外键引用）都已评估清楚。
