维权提醒：如果你或身边的朋友近五年内因投顾公司虚假宣传、诱导交费导致亏损，别放弃！立即联系小羊维权（158 2783 9931，微信同号），专业团队帮你讨回公道！
> 原文地址：https://www.bytebase.com/blog/what-is-new-in-postgres-18
PostgreSQL 于 2025 年 5 月 8 日宣布了 18 beta 1 版本的发布。虽然一些功能可能还会被移除，但值得一看。
异步 I/O
PostgreSQL 18 在底层引入了一个重大改进，即新的异步 I/O（AIO）子系统。根据官方的版本说明，此功能旨在提高 I/O 吞吐量并隐藏 I/O 延迟，可以通过 io_method 服务器变量启用。对于 Linux 用户，这意味着可以利用 io_uring，而且可在任意平台基于工作线程实现。原实现方式主要针对文件系统读取，包括顺序扫描、位图堆扫描和清理操作；新的系统视图 pg_aios 也将可显示用于 AIO 的文件句柄。
> 终于有 AIO 了！承诺某些读取操作 2-3 倍的性能改进，听起来很棒（对使用网络附加磁盘的云数据库来说，真的有可能）。 > > 不过别忘了，这只是针对读取的；不要指望你的写入密集型 OLTP 会一夜间神奇地加速。当然，AIO 仍是一个巨大的进步，如果没有引入新 I/O 错误的话。 > DBA Note
UUIDv7
PostgreSQL 18 为处理分布式系统或需要全局唯一、可排序标识符的开发者带来了对 UUIDv7 的原生支持。正如 PostgreSQL 18 Beta 1 发布公告中所强调的，新的 uuidv7() 函数允许生成按时间戳排序的 UUID。相比传统的 UUID（如 UUIDv4，uuidv4() 现在是 gen_rand_uuid() 的别名），这在数据库性能方面是一个重大改进，尤其是对于索引和缓存策略，因为按时间排序的特性可以带来更好的数据局部性并减少 B 树索引中的页面分裂。
> 现在，我们的主键就既可以全局唯一，又可以与索引很好地配合。迟到总比不到好。 > > DBA Note
改进的 EXPLAIN
EXPLAIN 命令在理解查询性能方面是 DBA 最好的朋友（有时也是最大的敌人）。PostgreSQL 18 为 EXPLAIN 的输出带来了几个正向的改进，使其更有洞察力。根据版本说明，EXPLAIN ANALYZE 现在将自动包含 BUFFERS 输出，省去了额外的关键字。此外，改进后的 EXPLAIN ANALYZE VERBOSE 将显示 WAL（预写日志）使用情况、CPU 统计信息和平均读取统计信息。EXPLAIN (WAL)、VACUUM/ANALYZE (VERBOSE) 和自动清理日志输出中还添加了完整的 WAL 缓冲区计数。
> 也许，仅仅是也许，现在更多的开发者会真正查看缓冲区使用情况。VERBOSE 中的 WAL、CPU 和平均读取统计数据很有助于真正深入的分析；还有一个指标可以将自动清理跟不上的原因解释得一清二楚。 > > DBA Note
NOT NULL 约束作为 NOT VALID
PostgreSQL 18 引入了另一个对 schema 管理的有益改进，即能够将 NOT NULL 约束添加为 NOT VALID。
此功能允许用户添加 NOT NULL 约束而无需立即扫描整个表，之后验证时也无需持有 ACCESS EXCLUSIVE 锁。这对于大表特别有价值，可以大量节省添加约束所需的停机时间。
这个新语法需要使用命名约束方法：
ALTER TABLE table_name ADD CONSTRAINT constraint_name NOT NULL (column) NOT VALID;
之后，可以使用以下方式验证约束：
ALTER TABLE table_name VALIDATE CONSTRAINT constraint_name;
在验证期间，PostgreSQL 只持有 ShareUpdateExclusiveLock，这意味着 SELECT、INSERT、UPDATE 和 DELETE 等正常操作可以在验证过程运行时继续工作。
即使 NOT NULL 约束被添加为 NOT VALID，它仍然阻止新的 NULL 值插入到列中。这为新行提供了即时的数据完整性，并允许在任何时候清理现有的 NULL 值。
> 这对于我们这些以每秒美元计算停机时间、管理大型生产数据库的人来说，简直是雪中送炭。我们不再需要为了给某个 10TB 的表添加 NOT NULL 约束而安排凌晨 3 点的维护窗口。被标记为无效时仍然阻止新的 NULL 值，这是完美的平衡：向前传递完整的数据，而不必立即验证。 > > DBA Note
RETURNING 中的 OLD/NEW 值
以前的 RETURNING 为 INSERT 和 UPDATE 返回新值，为 DELETE 返回旧值；MERGE 操作根据所执行的内部查询来返回值。新语法则更加灵活，允许 INSERT ON CONFLICT 和 UPDATE 返回旧值（以前 UPDATE 只有新值），DELETE 在 ON DELETE 行赋值产生新值时可能返回新值。可通过更改关系别名「old」和「new」来指定所需的值。
> 这很好地简化了应用程序逻辑。今后要获取前后对比，就不再需要处理繁复的 SELECT 语句或触发器了。 > > DBA Note
虚拟生成列
根据版本说明，PostgreSQL 18 改变了生成列的处理方式，「在读取时（而非写入时）计算其值」。有别于传统的 STORED 生成列，虚拟生成列成为了默认值；尽管STORED 选项仍然可用于需要显式写入时计算和存储的场合。PostgreSQL 18 Beta 1 还宣布，存储的生成列现在可以逻辑复制。
> 鉴于相当多的的全名或简单计算，对于从其他列派生且无需物理存储的列，这样会节省大量磁盘空间和写入开销。代价是读取时计算，意味着查询这些虚拟列可能受轻微的性能影响，特别是生成逻辑复杂的情况下；因此，存储的列可进行逻辑复制，是一个不错的补充。 > > DBA Note
主要版本升级体验
许多 DBA 升级 PostgreSQL 主要版本会有顾虑。
变更仍主要采取 pg_dumpall 后恢复、使用 pg_upgrade、逻辑复制等标准操作，但 PostgreSQL 18 将改善此过程的体验。
新版本说明强调了通过主要版本升级保持规划器统计信息的能力；新升级的集群可以更快达到预期的性能状态，而无需等待跨所有数据的 ANALYZE 运行。pg_upgrade 本身性能也有提升，包括其检查的并行处理（通过 --jobs 标志）和新的 --swap 标志（交换而非复制升级目录），在大型安装场景下可以节省大量时间。
当然，任何主要版本都需要注意兼容性问题。版本 18 的说明中列出了几个：时区缩写处理的变化、MD5 密码认证的弃用（终于！）、VACUUM 和 ANALYZE 处理继承的变化、COPY FROM 关于文件结束标记行为的修改等。升级之前彻底审查兼容性是至关重要的。
> 只要能消灭升级时那个可怕的维护窗口的，都是好东西。当然，不兼容性列表这个陷阱仍然存在，DBA 仍需要阅读细则、彻底测试，并保留一个可靠的回滚方案。升级仍然是 DBA 赚危险津贴的场合。 > > DBA Note
💡 更多资讯，请关注 Bytebase 公号：Bytebase
</div>
