跨schema JOIN慢的本质是数据库未走索引或未视作本地表优化，主因包括search_path未正确设置、缺失跨schema索引、schema USAGE权限不足及统计信息过期。
跨schema JOIN 为什么慢得离谱
本质是数据库没走索引，或者压根没把跨schema的表当“本地表”优化。PostgreSQL 默认对 schema_a.table1 和 schema_b.table2 做 JOIN 时，若没显式指定搜索路径或没建跨schema索引，优化器容易放弃嵌套循环，退化成哈希JOIN甚至多次全表扫描。
- 常见错误现象：
EXPLAIN ANALYZE显示Seq Scan在大表上反复出现，Buffers高得异常 - 根本原因：目标表不在
search_path里，导致 planner 无法预判统计信息完整性，不敢用索引 - 别指望视图或同义词（PostgreSQL 没同义词）自动加速——它们不改执行计划
必须设 search_path，但不能乱设
search_path 不是“加个 schema 名就完事”，顺序和权限直接决定能否执行、走不走得通索引。
- 正确写法：
SET search_path = 'schema_a', 'schema_b', 'public';—— 把高频 JOIN 的 schema 放前面 - 危险操作：
SET search_path = 'public', 'schema_a';—— 如果table1在schema_a但 public 里也有同名表，就会误用 public 的表或报错 - 权限影响：用户必须对所有出现在
search_path中的 schema 有USAGE权限，否则SET成功但后续查询仍报permission denied for schema xxx - 连接级生效：在应用里用
pg_set_client_encoding类似方式，在连接初始化时执行一次即可，别每次查询前都 SET
跨schema字段关联必须建索引，且索引要带schema前缀
别信“主键自动有索引”——跨schema时，外键约束可以建，但索引不会跨schema自动复用。你得手动在被 JOIN 的字段上建索引，而且 DDL 必须写全 schema 名。
- 错误示例：
CREATE INDEX idx_user_id ON orders(user_id);—— 这只在当前 schema 生效，如果orders在salesschema，这条语句实际建在public.orders或当前默认 schema - 正确写法：
CREATE INDEX idx_sales_orders_user_id ON sales.orders(user_id); - 复合场景：如果 JOIN 条件是
schema_a.t1.id = schema_b.t2.ref_id，两个字段都要单独建索引；若常查t2.ref_id AND t2.status，就在schema_b.t2上建联合索引：CREATE INDEX idx_t2_ref_status ON schema_b.t2(ref_id, status); - 注意：索引名不用带 schema，但表名必须带，否则可能建错地方
权限配置漏掉 USAGE 就等于白搭
很多人给了 SELECT 权限就以为万事大吉，结果一执行 JOIN 就报错。PostgreSQL 要求对 schema 本身有 USAGE，才能访问其下的对象——哪怕你已经有那张表的 SELECT 权限。
- 典型报错：
permission denied for schema analytics，即使你对analytics.fact_events有 SELECT 权限 - 补权限命令：
GRANT USAGE ON SCHEMA analytics TO app_user; - 批量授权脚本别偷懒：
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO app_user;不会自动附带USAGE，必须单独给 - 命名空间规范建议：业务域强相关的表尽量收进同一 schema（比如
payment.*、user_profile.*），避免 JOIN 散落在 5 个 schema 里——不是不能做，是每多一个 schema，就要多验一次USAGE，多一次 search_path 排序风险
最常被跳过的其实是 ANALYZE：跨schema表一旦数据量变化大，旧统计信息会让 planner 彻底误判。别只在建表后跑一次，要在 ETL 后或批量导入后主动执行 ANALYZE schema_a.large_table;，不然再好的 search_path 和索引也救不了执行计划。
