PostgreSQL 18 新特性详解：异步 IO、Skip Scan、UUIDv7 都来了

PostgreSQL 18 是一次实打实的大版本更新：异步 I/O 重写读取路径、生成列默认改为虚拟列、多列索引支持 Skip Scan、新增时态约束和 UUIDv7，还有一批升级体验与可观测性改进。下面逐项拆解。

1. 异步 I/O：读取性能架构级升级

以往后端进程读数据页是同步的——每次 I/O 都要等上一个完成才能发起下一个，顺序扫描、位图堆扫描、VACUUM 这类操作深受其害。

PostgreSQL 18 引入异步 I/O 子系统，后端可以一次性排队多个读请求，把 I/O 调度优化交给操作系统，吞吐明显提升。相关新参数：

• io_method：控制 I/O 方式；
• io_combine_limit / io_max_combine_limit：控制请求合并批处理的细粒度；
• 无 fadvise() 支持的平台上，effective_io_concurrency 和 maintenance_io_concurrency 大于 0 也能带来收益，平台间表现更均衡。

新增的 pg_aios 系统视图可查看正在使用的异步文件句柄。深度解读见本系列《PostgreSQL 异步 IO 详解》。

2. 虚拟生成列成为默认

生成列不再默认物理存储。PostgreSQL 18 起默认是虚拟列（Virtual）：读时计算，不占磁盘，写入时也无需维护。

-- PostgreSQL 18：默认虚拟列，查询时才计算
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    price NUMERIC(10,2),
    tax_rate NUMERIC(3,2),
    total_price NUMERIC(10,2) GENERATED ALWAYS AS (price * (1 + tax_rate))
);

如果某列处于性能关键的读取路径、需要预计算结果，显式加 STORED 即可回到旧行为。设计原则变成：按访问模式自由选择"读时算"还是"写时存"。

3. Skip Scan：多列索引潜力释放

以前多列 B-Tree 索引有个著名短板：查询不带前导列条件时，索引基本用不上。PostgreSQL 18 支持 Skip Scan——优化器可以跳过前导列、直接利用索引定位非前导列上的条件，很多原本只能全表扫描的查询现在能走索引。详解见《PostgreSQL Skip Scan 详解》。

4. 时态约束（Temporal Constraints）

新增 WITHOUT OVERLAPS 等时态约束能力，可以在数据库层直接声明"同一资源的时间段不允许重叠"——会议室预订、排班、租约这类场景，以前要靠触发器或应用层代码防重叠，现在一条约束搞定。详解见《PostgreSQL 时态约束详解》。

5. UUIDv7：为分布式系统而生

内置支持 UUID 版本 7。与随机 UUIDv4 不同，UUIDv7 按时间有序，作为主键对 B-Tree 索引极其友好（避免随机写导致的索引膨胀和页分裂），同时保留全局唯一性，是分布式系统主键的现代答案。详解见《PostgreSQL 18 的 UUID 支持》。

6. RETURNING 支持 OLD 和 NEW

RETURNING 子句现在可以同时引用 OLD 和 NEW，一条 UPDATE/DELETE 就能拿到修改前后的完整行，审计日志、变更捕获场景的 SQL 大幅简化。详解见《RETURNING 中的 OLD 与 NEW》。

7. 升级体验改进

• 统计信息保留：以前 pg_upgrade 后必须对整个集群重新跑 ANALYZE，否则优化器"失明"一段时间；PostgreSQL 18 升级时自动保留统计信息，新集群上线即有准确的执行计划；
• 校验和（checksums）变化：新版本默认启用数据校验和，升级时需确认新旧集群设置一致（必要时用 initdb 参数匹配），这是最值得注意的破坏性变更之一。

8. 安全与可观测性

• OAuth 认证：新增 OAuth 认证方式，企业身份体系集成更顺；
• 监控增强：pg_aios 之外还有多项统计与等待事件改进，DBA 定位性能问题的视角更全。

要不要升级？

升级理由：读取吞吐提升、索引利用率更高、升级后无需漫长 ANALYZE——对读密集型和大型库收益直接。

升级前检查清单：

# 1. 检查旧集群校验和设置
pg_controldata /path/to/old/data | grep checksum

# 2. 用匹配的设置初始化新集群
initdb -D /path/to/new/data --data-checksums  # 或按需不加

# 3. 执行升级（统计信息自动保留）
pg_upgrade -b /old/bin -B /new/bin -d /old/data -D /new/data

生产库升级前务必在测试环境完整演练，并确认插件兼容性。

观测云对照

升级版本后更要盯紧数据库表现。观测云 DataKit 集成支持采集 PostgreSQL 指标（连接数、事务、慢查询、锁等待等），接入后可在仪表板对比升级前后的吞吐与延迟，用监控器为慢查询率、连接使用率设告警，让"升级有没有带来预期收益"用数据说话。 1 2

常见问题（FAQ）

Q：PostgreSQL 18 最大的性能亮点是什么？
异步 I/O。它把读取路径从"串行等待"变成"并行排队"，顺序扫描、VACUUM 等场景直接受益，无需改应用代码。

Q：虚拟生成列和存储生成列怎么选？
默认用虚拟列（省存储、写入快）；当计算代价高且查询频繁、读路径要求极低延迟时，改用 STORED。

Q：从 16/17 直接升 18 可以吗？
可以，pg_upgrade 支持跨版本升级。重点检查校验和设置一致性、扩展插件兼容性，并先在测试环境演练。

Q：UUIDv7 能直接当主键替换自增 ID 吗？
可以，且对分布式场景比自增 ID 友好（无需中心发号）。因时间有序，索引写入性能远好于 UUIDv4。

参考资料

• 观测云 PostgreSQL 集成与数据采集
• 观测云监控器与告警