Navicat 连接的是数据库而非 schema，schema 是库内逻辑空间，依赖 search_path 决定默认查找路径；需通过会话级 SET、连接级 Options 或用户级 ALTER ROLE 固化 search_path 才能生效。
navicat 本身没有“连接到某个 schema”的概念——它连接的是数据库（database），不是 schema；schema 是数据库内的逻辑命名空间，必须靠 search_path 控制默认行为。
为什么“连接时指定 Schema”这个说法容易误导
PostgreSQL 的连接目标是 database（如 myapp_prod），而 schema（如 analytics、sales）只是该库内部的容器。Navicat 的连接配置里根本没有 “Schema” 字段。用户常以为填了 schema 就能“进到那里”，结果新建表仍落在 public，或查不到表，本质是没理解 search_path 的作用机制。
- Navicat 新建表、执行查询时，所有未显式带 schema 前缀的对象（如
SELECT * FROM users），都依赖当前会话的search_path -
search_path默认值通常是"$user", public或public，不是你期望的业务 schema - 即使你在 Navicat 对象树里右键某个 schema → “新建表”，它生成的 DDL 仍可能不带 schema 前缀，最终还是走
search_path
真正生效的三种方式（按优先级排序）
想让 Navicat 的操作默认落在指定 schema（比如 reporting），必须从会话级或用户级固化 search_path：
-
会话级临时设置（推荐用于调试/单次连接）：在 Navicat 查询窗口执行
SET search_path TO reporting, public;。之后所有未加前缀的操作都优先查reporting下的对象 -
连接级自动设置（最常用）：编辑 Navicat 连接属性 → “Advanced” 页签 → 在
Options输入框填：-c search_path=reporting,public。这样每次连上就自动生效，无需手动跑 SET -
用户级永久设置（适合固定角色）：用超级用户执行
ALTER ROLE myuser SET search_path TO reporting, public;。此后该用户所有连接（无论是否通过 Navicat）都默认使用此路径
常见错误现象与对应检查点
即使设置了 search_path，仍可能看不到表或建错位置，重点排查这些：
- 执行
SHOW search_path;确认输出确实是reporting, public，而不是"$user", public（此时若用户名为myuser，会先找myuserschema，而非reporting） - 确认
reportingschema 真实存在：SELECT schema_name FROM information_schema.schemata WHERE schema_name = 'reporting'; - 确认当前用户对该 schema 有
USAGE权限：GRANT USAGE ON SCHEMA reporting TO myuser;，否则 Navicat 对象树里根本不会展开它 - Navicat 对象树默认隐藏非
publicschema：右键数据库 → “Refresh”，再检查“选项”→“对象过滤器”是否勾选了“显示所有 Schema”
逆向工程或导出时如何限定 Schema
Navicat 的「转储 SQL 文件」功能无法按 schema 过滤，但「导出向导」可以：
- 在对象树中展开目标数据库 → 展开
SCHEMAS→ 找到并点击reporting→ 展开其下的所有表 → Ctrl+A 全选 → 右键 → 「导出向导」→ 格式选 SQL → 勾选「导出 USE 语句」 - 若需跨 schema 导出或保证外键关系完整，直接用命令行：
pg_dump -U myuser -h host -d mydb --schema=reporting --no-owner --no-privileges > reporting.sql - 逆向工程时，务必取消勾选「Only show objects in current schema」，否则即使
search_path设对了，Navicat 也只扫public
真正关键的不是“怎么连”，而是“连上后 PostgreSQL 按什么规则找对象”。search_path 是唯一开关，但它受权限、客户端缓存、界面默认行为三重影响——漏掉任一环，schema 就像隐身了一样。
