Navicat 17 将 PostgreSQL 的 BTREE 索引误识别为 HASH，是因其硬编码 AM OID 映射表不全且对 pg_am.amname 错误小写化导致匹配失败；真实类型应通过 SELECT indexdef FROM pg_indexes 验证，临时解决需设置 search_path 并确保版本兼容。
Navicat 17 逆向工程把 BTREE 索引识别成 HASH 怎么办
navicat 17 在 postgresql 逆向工程中，会将系统目录里 pg_index 的 indam 字段映射为索引类型，但它的映射表硬编码了几个常见 am（access method）oid，而 postgresql 12+ 默认用 btree，新版本又支持 brin、gin、gist 等，navicat 17 对非 btree 的 am 名称解析不全，尤其遇到自定义 am 或 extension 提供的索引类型时，容易 fallback 成 hash（一个它“认识”但 postgresql 实际不支持的占位类型）。
这不是数据库本身的问题，而是 Navicat 解析 pg_am.oid 和 pg_class.relname 关联逻辑有缺陷。你查 \d+ table_name 显示的是 btree，但 Navicat ER 图里标成 HASH——这就是典型症状。
- 确认真实索引类型：在 psql 中执行
SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'your_table';，看USING btree是否存在 - 检查访问方法名是否被小写化：Navicat 17 某些版本对
pg_am.amname做了不安全的lower()，导致'btree'变成'BTREE'后匹配失败 - 临时绕过：在逆向前手动执行
SET search_path TO pg_catalog, public;（确保 Navicat 查询系统表时不走别名或视图干扰）
MySQL 场景下 UNIQUE INDEX 被识别成 PRIMARY KEY
Navicat 17 解析 MySQL 的 SHOW CREATE TABLE 输出时，只靠关键字顺序和字段名重复性做启发式判断。当表里有 UNIQUE KEY `uk_email` (`email`)，且该字段恰好是 NOT NULL，它就可能误判为隐式主键——尤其在没有显式 PRIMARY KEY 定义的表中。
这种错误不会报错，但会导致 ER 图里出现一条本不存在的 PK 标识线，后续生成 DDL 或同步结构时可能覆盖原设计。
- 验证方式：右键表 → “对象信息”，看“索引”页签里
Is Primary列是否为Yes，再对比SHOW CREATE TABLE输出中的PRIMARY KEY行是否存在 - 修复动作：不要依赖逆向结果直接导出，先在 Navicat 中手动编辑该索引，把
Primary Key勾选取消（即使灰显也要点一下） - 预防手段：建表时显式声明
PRIMARY KEY，哪怕只是id SERIAL PRIMARY KEY，避免让 Navicat 猜测
PostgreSQL 自定义域（domain）索引无法识别
当你用 CREATE DOMAIN email AS VARCHAR(255) CHECK (...)，再在表中用 contact_email email，Navicat 17 逆向后常把该字段索引标为 UNKNOWN 或直接忽略——因为它只认基础类型（如 varchar），不递归解析 domain 的底层类型和约束链。
这会影响 ER 图的完整性，也导致后续“查找引用”功能失效（比如搜不到哪个索引加速了 email 查询）。
- 必须提前运行：
SET search_path TO pg_catalog, public, your_domain_schema;，否则 Navicat 连pg_type都查不全 domain 定义 - 逆向前，在 Navicat 连接属性→高级→Options 中，确保
search_path包含 domain 所在 schema，且顺序正确 - 如果 domain 带
NOT NULL，Navicat 可能把它当成“主键候选”，需人工核对索引列表，删掉误加的 PK 标识
跨 schema 外键索引丢失，但外键本身能识别
PostgreSQL 允许在 myschema.orders 上建索引，而外键指向 public.users.id。Navicat 17 能识别外键约束（因为查 pg_constraint），但索引只扫描当前 schema 的 pg_index，导致 public.users_id_idx 不出现在 ER 图中——于是你看到外键连线，却看不到支撑它的索引。
这个问题隐蔽性强：ER 图看着完整，实际查询可能全表扫 users。
- 必须在逆向前，用 psql 验证目标表是否有索引：
\d public.users，确认Indexes:下有对应字段的 btree - Navicat 里不能只勾选
myschema，要 Ctrl+多选myschema和public（或其他被引用 schema），再一起逆向 - 若仍缺失，手动在 Navicat 中为
public.users表执行一次“刷新对象”，再重新生成 ER 图
