解读

在国内互联网与金融场景里，PostgreSQL 常被拆成多个 schema 做“逻辑分库”或“多租户”隔离，例如订单系统按年分 schema：orders_2022、orders_2023。
search_path 决定解析未带 schema 限定的对象时，引擎按什么顺序去“找表”。
面试时，考官想听你回答两层：

1. 解析阶段如何产生额外系统 catalog 查询；
2. 执行阶段如何因 plan cache 失效、索引误选而放大 RT 与 CPU。
   答出“软解析风暴”“plan cache 污染”“索引错位”三个关键词，就能与国内高并发、低延迟的痛点对齐。

知识点

1. 软解析（parse）：每条不带 schema 的 SQL 都要沿 search_path 顺序对 pg_class、pg_namespace 做线性查找，直到命中或报错；路径越长，catalog 扫描次数越多。
2. plan cache 键值：Prepared Statement 的缓存键包含“实际解析出的 schema 名”。search_path 一旦变化，同一文本 SQL 被视为新入口，缓存失效，出现硬解析风暴。
3. 索引错位：若不同 schema 存在同名表但索引不同（orders_2022 有 idx1，orders_2023 只有 idx2），plan 被复用到“错误 schema”时，优化器可能选全表扫描，导致RT 抖动。
4. 权限回退：search_path 中排位靠前的 schema 若存在同名对象，即使当前用户无权限，也会先被解析到，抛出权限错误而非继续向后匹配，增加一次 round trip。
5. Cloud SQL 监控：Google Cloud SQL 提供的 pg_stat_statements 只能看到最终执行 schema，看不到因 search_path 导致的多次软解析耗时，容易漏判根因。

答案

search_path 的性能陷阱本质是“解析不确定性带来的放大效应”。
当客户端未显式写 schema 时，后端必须沿 search_path 顺序在系统表里逐条查找对象；每多一个 schema，就至少多一次索引扫描 pg_class_oid_index 与 pg_namespace_nspname_index。高并发下，这些轻量级调用会变成全局热点 catalog 块，CPU 空耗在 LWLock:ProcArray 与 BufferPin。
更严重的是，plan cache 以“解析后的 schema”为键。若连接池为不同租户反复切换 search_path，同一条 SQL 文本会被硬解析多次，共享内存出现大量近乎重复的执行计划，挤占 Cloud SQL 有限的 buffer_pool，触发 LRU 淘汰，进而把真正热点计划也清掉，QPS 曲线出现“锯齿抖动”。
最后，如果各 schema 的同名表统计信息差异大，复用计划会导致索引错位，一条本该 5 ms 的点查可能变成 300 ms 的 seq scan；在阿里双 11、字节红包这种国内峰值场景下，RT 放大直接触发熔断。
规避手段：

1. 业务侧一律带 schema 写 SQL，把解析成本降为零；
2. 连接池按租户做物理分池，禁止动态 SET search_path；
3. 对必须动态访问的 schema，使用 PL/pgSQL 动态 SQL + USING 参数，确保 plan 每次重新生成，避免污染全局缓存；
4. 在 Cloud SQL 中打开 auto_explain 与 pg_stat_statements.track = 'all'，把解析耗时也纳入 SLI，方便快速定位 search_path 引起的毛刺。

拓展思考

1. 国内某券商核心交易库把 3000 只股票的逐笔数据按股票代码分 3000 个 schema，早盘高峰 8 万 QPS，因 JDBC 连接池复用导致 search_path 每轮切换，CPU 30 % 花在 catalog 扫描。最终采用“代码生成+显式 schema”重构，解析耗时下降 92 %，P99 从 120 ms 降到 15 ms。
2. 在 Cloud SQL for PostgreSQL 15 的企业版并行查询场景下，search_path 过长还会让并行 worker 重复解析，放大 Coordinator 瓶颈；此时可结合 google_sql_tuner 建议，把 search_path 固化到用户级默认，并打开 plan_cache_mode = force_generic_plan，强制走通用计划，减少重复计算。
3. 如果业务必须使用动态 schema，可考虑把热点表做成逻辑分区表，用 PostgreSQL 12+ 的 partition pruning 替代 schema 隔离，既保留租户视角，又彻底规避 search_path 解析链。