PostgreSQL 18 性能飞跃：真实查询场景下的 5 大核心优化

由 John Doe 七月 23, 2026

还在犹豫要不要升级 PostgreSQL 18？快来了解一下它相对 PostgreSQL 17 性能提升的场景吧。

目录

基于相同的硬件环境（Azure 同等算力与存储）和真实的业务数据规模（2万至500万行），对比测试 PostgreSQL 17 与 PostgreSQL 18 可以发现，PG 18 在底层规划器和执行器上做出了大幅度升级。最重要的是：开发者完全不需要修改现有的 SQL 语句或应用代码，只需升级版本即可获得这些巨大的性能红利。

以下是 PostgreSQL 18 带来的五大核心查询性能提升对比：

多个 OR 条件的自动改写

在日常开发中，多状态、多类别的过滤查询极为常见（如：WHERE status = A OR status = B...）。

  • PostgreSQL 17 的瓶颈：每一个 OR 条件都会触发其独立的索引扫描，生成各自的位图（Bitmap），最后由规划器执行合并。OR 条件越多，性能开销呈线性增长。
  • PostgreSQL 18 的优化：规划器能够自动将多个 OR 链改写为带有 ANY 表达式的单一纯索引扫描。它跳过了数组查找，且无需执行合并步骤。
  • 测试结果：包含 5 个 OR 条件的查询，耗时从 34 毫秒降至 19 毫秒（性能提升 43%）。在单秒被调用上千次的高频 API 中，这将极大地释放 CPU 资源。

image

复合索引的跳跃扫描 —— 提升幅度最大

开发者常因为不符合“最左前缀法则”而导致复合索引失效。例如建立复合索引 (Exchange, Trade_ID)，但在查询时只过滤 Trade_ID，不带 Exchange 条件。

  • PostgreSQL 17 的瓶颈：只能通过大范围扫描复合索引并进行“后置过滤”，读取了海量的无用数据（测试耗时 121 毫秒）。
  • PostgreSQL 18 的优化：引入了跳跃扫描（Skip Scan）机制。系统会在内部迭代首列（Exchange）的去重值，并针对每一个去重值，直接向后执行目标精准查找以匹配第二列（Trade_ID）。
  • 测试结果：耗时从 121 毫秒暴降至 0.07 毫秒（提速约 741 倍，执行时间减少 99.9%）。
  • 关键结论：首列字段的“基数”（Cardinality，即不重复值的个数）越低（如状态、区域、交易所等），跳跃扫描带来的性能优势越巨大。

image

冗余自连接消除

由 ORM 框架（如 Django、Hibernate）或微服务复杂视图底层，经常会产生针对同一个表基于主键的冗余“自连接”。

  • PostgreSQL 17 的瓶颈：机械地将其视为合法连接，对同一张表和索引进行两次扫描并执行合并连接（Merge Join），做了双倍无用功。
  • PostgreSQL 18 的优化：规划器通过 inner rel is unique 机制侦测自连接，如果连接字段是主键或唯一键，系统会自动证明其行匹配的唯一性，并将自连接直接消除，替换为语义相同的单次扫描。（此功能由 enable_self_join_elimination 参数控制，默认开启）。
  • 测试结果：耗时从 6.29 毫秒降至 1.28 毫秒（提速约 5 倍）。
  • 注：目前该优化仅适用于基础表，尚未覆盖 CTE 或子查询中的自连接。

image

针对唯一索引的 Group By 剪枝

针对多列执行 GROUP BY 时（如：GROUP BY ID, Ticker, Name），如果其中某列（Ticker）设有唯一索引且不为空（NOT NULL），其余列的值其实已经被唯一确定。

  • PostgreSQL 17 的瓶颈：只支持基于“主键”的剪枝。若只是唯一索引，规划器仍会老老实实对所有列进行分组操作。
  • PostgreSQL 18 的优化：强化了剪枝能力，识别出基于非空唯一索引的功能依赖，自动裁切掉冗余的分组键。
  • 测试结果：耗时从 13 毫秒锐减至 0.05 毫秒。复杂的聚合操作被成功转换为极简的纯索引扫描，同时消除了多余的排序逻辑。

image

集合操作执行器清理

用于寻找数据集差异的 EXCEPT 或是取交集的 INTERSECT 操作。

  • PostgreSQL 17 的瓶颈：执行计划涉及大量的底层管道工序（如 Append 节点、繁琐的子查询扫描等）。
  • PostgreSQL 18 的优化：并非通过改变查询结构，而是深度重构和清理了哈希集合操作的底层执行器，支持直接基于索引扫描的结果进行操作，并启用短路（Short-circuit）特性。
  • 测试结果：提速约 1.5 倍。相比前几个优化看似幅度不大，但作为纯底层机制的改善，意味着你所有的 EXCEPT 和 INTERSECT 操作都能无差别提速。

image

总结与升级建议

  1. 升级建议：强烈推荐。对于绝大多数读写繁重的业务场景（尤其是读密集型），PG 18 带来了近乎免费的巨大性能飙升。在完成标准测试流程后，建议果断升级。
  2. 零代码入侵：享受这些提速不需要改变架构、不需要优化现有的糟糕 SQL，核心工作由变聪明的规划器（Planner）全权代劳。
  3. 超越查询本身的提升：除了上述查询优化，PG 18 在大规模分区表管理、高并发 OLTP 场景下的规划器与锁稳定性、以及监控可观测性上同样有着卓越的进步。

参考

PostgreSQL 17 vs 18: Side‑by‑Side Performance Wins in Real‑World Queries

搜索

分类

标签