跨 schema 表 JOIN 必须显式写全表名，因 search_path 可能导致查错表或报错；JOIN 字段需单独建索引，权限需提前授予 USAGE；统计信息应定期更新。
跨 schema 表 JOIN 必须显式写全表名（schema_name.table_name），否则 PostgreSQL 会按 search_path 查找，极大概率查错表或报错。
为什么不能省略 schema 名直接写 table_a JOIN table_b
PostgreSQL 默认只在 search_path 列表里的 schema 中找表。哪怕两个表物理上都存在，只要没被当前 search_path 覆盖，就会报 relation "xxx" does not exist；更隐蔽的问题是：如果两个 schema 都有同名表，而你没写 schema，数据库可能选错一个——结果错得毫无提示。
- 必须写
schema_a.users和schema_b.orders，不能只写users和orders -
search_path只影响“未加 schema 前缀”的查找行为，对显式带 schema 的语句完全无影响 - 即使两个表都在
public，也建议写public.table_name——避免未来迁移时因search_path变动导致隐性故障
JOIN 条件字段没索引？查询会慢到不可用
跨 schema JOIN 不会自动复用对方 schema 的索引，哪怕字段名、类型、约束都一样。数据库优化器看到 schema_a.t1.id = schema_b.t2.user_id，若 schema_b.t2.user_id 没索引，就会对整个 t2 表做顺序扫描。
- 在 JOIN 条件中出现的字段，每个都要单独建索引：
CREATE INDEX ON schema_b.t2(user_id); - 如果还常加
WHERE t2.status = 'active'，就建联合索引：CREATE INDEX ON schema_b.t2(user_id, status); - 索引名不用带 schema，但
ON后面的表名必须带，否则可能建到当前默认 schema 下
权限不足时，SET search_path 成功但查询仍失败
很多人执行了 SET search_path TO schema_a, schema_b;，接着跑 SELECT * FROM users JOIN orders ...，结果报 permission denied for schema schema_b——这是因为 USAGE 权限没给够。
- 用户必须对所有涉及的 schema 都有
USAGE权限，否则哪怕表存在、自己有SELECT权限，也会在解析阶段拒绝访问 - 授予权限命令：
GRANT USAGE ON SCHEMA schema_b TO your_user; -
search_path是连接级生效，应用里应在建连后立即执行一次SET，别每次查询前都 SET
别依赖“主键自动有索引”来跨 schema 关联
主键约束本身只保证唯一性和非空，它附带的索引仅作用于本 schema 内。跨 schema JOIN 时，优化器不会把 schema_a.t1.id 的主键索引“映射”过去加速 schema_b.t2.ref_id 的查找。
- 外键可以跨 schema 创建（如
ALTER TABLE schema_b.t2 ADD FOREIGN KEY (ref_id) REFERENCES schema_a.t1(id)），但这不等于自动建索引 - 跨 schema 外键引用字段，仍需手动在
schema_b.t2.ref_id上建索引，否则 JOIN 性能崩塌 - 统计信息过期也会让优化器误判执行计划，定期运行
ANALYZE schema_b.t2;
最易被忽略的是：权限和索引这两件事，必须在写 SQL 前就确认到位。光把 JOIN 语句写对，只是跨出了第一步。
