Navicat 17 不支持对“分库分表”结构逻辑聚合后统一备份，因其“逻辑连接”仅用于界面分组，备份操作必须绑定单个物理连接与数据库，无法跨库识别同构表、合并元数据或生成联合.psc/.nb3包；可行方案是为每个分库单独建Backup任务，统一路径命名，再通过批处理作业顺序执行并外部归档压缩。
navicat 17 不支持对“分库分表”结构做逻辑聚合后统一备份——它没有跨连接自动识别同构表、合并元数据或生成联合备份包的能力。所谓“通过逻辑连接聚合后统一备份”，本质是用户误把 数据传输 或 数据同步 功能当成了备份功能。
为什么不能用“逻辑连接”实现分库分表统一备份
Navicat 的“逻辑连接”仅用于界面分组显示，不改变底层连接行为；每个数据库连接仍独立维持自己的认证、字符集、版本协议和权限上下文。备份操作（Backup）必须绑定到单个物理连接+单个数据库名，无法跨连接拼接表结构或数据流。
-
Backup任务生成的是.psc（MySQL）或.nb3（PostgreSQL）二进制包，含完整元数据快照，依赖目标库的运行时状态（如SHOW CREATE TABLE结果），无法在备份阶段动态推导“哪些表属于同一逻辑分片” - 即使你手动把多个分库（如
order_001、order_002）拖到同一个逻辑分组下，右键该分组仍不会出现“备份全部子库”选项 - 试图用
数据传输导出为 SQL 文件再合并，会丢失权限、存储过程、事件、触发器等非表对象，且无法保证事务一致性（比如某分库正在写入时被读取）
实际可行的替代路径：按分库逐个备份 + 后期脚本归档
这是目前唯一稳定、可审计、还原可控的做法。关键不是“一步到位”，而是确保每个分库备份独立可靠，再用外部工具聚合管理。
- 为每个分库（如
user_shard_01、user_shard_02）单独建一个Backup任务，保存路径统一设为D:\backups\sharded\20260427\下的子目录，文件名带分库标识，例如user_shard_01_202604271205.psc - 所有分库备份任务加入同一个批处理作业（
自动运行 → 新建批处理作业），按顺序执行；失败时日志明确标出哪个库卡住，不影响其余库 - 备份完成后，用 Windows 批处理或 PowerShell 脚本打包压缩：
tar -a -cf full_shard_backup_20260427.tar.gz D:\backups\sharded\20260427\，并生成校验码（certutil -hashfile full_shard_backup_20260427.tar.gz SHA256） - 切勿依赖 Navicat 自带的“导出为 SQL”做分库合并——它不处理
CREATE DATABASE语句冲突，也不重写表名前缀，还原时极易覆盖或报错
还原时最容易忽略的三个细节
分库分表场景下，还原不是“点一下打开文件”那么简单。以下三点漏掉任意一个，就可能让整个恢复流程失败。
- 每个分库必须提前手动创建，且排序规则（collation）必须与原库完全一致，否则
.psc还原时会静默跳过部分字段或报ERROR 1273 (HY000) - 还原顺序需与业务路由逻辑匹配：比如订单分库按时间分片，应从最早分片开始还原，避免应用层查询时因部分分片缺失而报空结果
- Navicat 还原不校验跨库外键约束（因为根本不认为它们有关联），若业务层有跨分库关联逻辑（如用中间表记录分库映射），这部分需人工核对并补全
真正难的不是操作步骤，而是确认“哪些库属于同一业务域”“它们的字符集/版本是否真的一致”“有没有被忽略的只读分库或影子库”。这些信息不在 Navicat 界面里，得查你的分库路由配置或 DBA 文档。
