PostgreSQL计划缓存是会话级执行计划缓存，仅对显式PREPARE/EXECUTE或libpq预编译接口生效；非全局共享，不缓存普通SQL字符串；JDBC默认模拟预编译，需配置prepareThreshold等参数启用真预编译。
PostgreSQL 的计划缓存（Plan Cache）对性能影响显著，尤其在使用 PreparedStatement（预编译语句）时。它不是简单“缓存 SQL 字符串”，而是缓存执行计划——即查询如何被执行的详细策略。理解这点，才能避免常见性能陷阱。
计划缓存如何工作
PostgreSQL 在服务端为每个客户端会话维护一个轻量级的计划缓存。当一条 SQL 第一次执行时，会经历解析 → 重写 → 规划 → 执行四个阶段；后续相同语句（字面完全一致，含空格、大小写）若参数未变，可复用已生成的执行计划，跳过规划开销。
但注意：PostgreSQL 不像 Oracle 那样有全局共享的 SQL Plan Cache。它的缓存是会话级的，且只对**显式 PREPARE / EXECUTE** 或 **libpq 的 PQprepare / PQexecPrepared** 等接口生效。普通 `SELECT` 直接发送字符串，不进入计划缓存流程。
PreparedStatement 并不总是“预编译”
很多开发者误以为 JDBC 中的 PreparedStatement 在连接建立时就编译好了。实际上：
- 默认情况下，JDBC 驱动（如 pgjdbc）采用“模拟预编译”：SQL 字符串只是做占位符替换，再以普通查询发送给服务器，不触发 PostgreSQL 的 PREPARE 协议；
- 只有开启
prepareThreshold>0（如设为 5），且同一条语句执行次数 ≥ 阈值后，驱动才会自动调用PREPARE命令向服务端注册命名计划； - 也可手动设置
preferQueryMode=extended+prepareThreshold=1强制走真正预编译，但需权衡首次开销与后续收益。
计划缓存可能成为性能瓶颈的场景
缓存本身高效，但不当使用反而拖慢性能：
-
绑定变量类型不一致：如某字段是
integer，第一次用 `?` 绑定整数，第二次却传入字符串 `'123'`，PostgreSQL 会因类型推导失败而拒绝复用计划，甚至报错； - 统计信息过期或数据倾斜严重：缓存的计划基于首次执行时的表统计信息生成。若之后数据量突增或分布剧变（如某值占比从 1% 变成 90%），原计划可能从 Index Scan 退化为 Nested Loop，性能骤降；
- 过度依赖通用计划：PostgreSQL 对带参数的 PREPARE 语句会生成“通用计划”（Generic Plan），忽略具体参数值。当某些参数值本该触发索引跳扫（Index Only Scan）或 BitmapScan，通用计划却选了 Seq Scan，就会浪费资源。
实用建议：让计划缓存真正帮上忙
不必禁用缓存，关键是用对方式：
- 确保参数类型稳定：在应用层做类型校验，避免把数字当字符串传；
- 定期执行
ANALYZE，尤其在大批量写入后，让优化器能生成更优初始计划； - 对关键查询，用
EXPLAIN (ANALYZE, BUFFERS)对比“第一次执行”和“多次执行后”的计划是否一致；若发现退化，可加/*+ SET enable_seqscan = off */（需安装 pg_hint_plan）临时干预，或改用EXECUTE ... USING显式指定参数强制生成专用计划； - JDBC 连接串中合理设置
prepareThreshold和reWriteBatchedInserts=true，批量操作优先受益于真正预编译。
基本上就这些。计划缓存不是银弹，也不是黑洞，它是 PostgreSQL 在“编译开销”和“执行适应性”之间做的务实权衡。用好它，需要一点观察，一点控制，不多，但不能忽略。
