是时候从 MySQL 转到 PostgreSQL 18 了

2025-11-17 17:06 Zongsoft 阅读(0) 评论(0) 收藏举报

是时候从 MySQL 转到 PostgreSQL 18 了

数据库技术革新的浪潮中，PostgreSQL 18 的发布标志着关系型数据库进入了新的时代，它不仅在性能上实现质的飞跃，更为开发者的工作效率带来了巨大提升。

近年来，随着应用复杂度的增加和数据规模的膨胀，许多基于 MySQL 的系统开始触及性能和维护的天花板。而 PostgreSQL 18 的发布，为这些挑战提供了全新的解决方案。

根据 db-engines.com 的趋势数据，PostgreSQL 是四大主流关系型数据库中唯一保持持续上升势头的系统，其受欢迎程度逐年攀升。这一趋势并非偶然，而是源于 PostgreSQL 在开发者友好性、性能、可扩展性以及 AI 趋势适应能力上的全面优势。

PostgreSQL 18 的异步 I/O 革命

PostgreSQL 18 引入了全新的异步 I/O（AIO）子系统，这是数据库性能领域的重大突破。与之前依赖操作系统预读机制的同步 I/O 不同，AIO 允许 PostgreSQL 并发地发出多个 I/O 请求，而不是等待每个请求顺序完成，这在云存储或低成本存储设备场景下的优势尤为明显。

实际测试表明，在顺序扫描、位图堆扫描等读取密集型场景中，性能可提升 2~3 倍。这对于实时读、数据仓库、报表分析等需要处理大量数据的场景尤其重要。

跳跃式扫描终结全表扫描噩梦

多列B树索引的 “最左前缀匹配” 限制，终于在 PostgreSQL 18 被打破了。新引入的跳跃式扫描(Skip Scan)技术，让查询能直接命中非首列的索引条件，彻底改变了此前必须全表扫描的尴尬处境。

举个实际例子，假设有 (a,b,c) 的联合索引，在以前版本中，执行 WHERE b >= 42 这样的查询会直接走全表扫描。而新版本会自动生成动态等式约束，逐个匹配 a 列的可能值并扫描对应 b 列范围，索引读取量最高可减少 90%。

更惊喜的是，非B树唯一索引现在能作为分区键使用，GIN索引也支持并行创建了。

RETURNING 支持获取新旧值

以往更新数据后要对比新旧值，要么写触发器要么查两次表。现在只需在 RETURNING 子句里加上 old.* 和 new.*，譬如：

UPDATE user
SET photo_path = '...'
WHERE user_id = 404
RETURNING old.photo_path, new.photo_path;

这在做数据审计或变更追踪时，这种代码能让你处理性能翻倍，并大幅简化业务层代码逻辑。

开发友好性

在涉及数据删除或更新的业务逻辑中，开发人员常常需要获取数据变动前的原始值，以执行相应的后续操作。一个典型的场景是：删除用户记录时，需要同时清理其关联的头像文件。这就要求在删除数据库记录前，先获取到该头像文件的存储路径。

传统的实现方式通常需要两次独立的数据库操作：先查询获取路径，再执行删除。这不仅增加了代码复杂性，还可能在并发场景下引发数据不一致的问题。

为了解决这一痛点，我们对 Zongsoft 数据引擎进行了改进，通过原生的 RETURNING 子句支持，将 查询原值 与 执行删除 合并为一个原子操作。这显著提升了代码的健壮性与简洁性，具体应用如下：

// 构建删除选项，明确指定需要返回的字段（例如用户的头像路径）
var options = DataDeleteOptions.Return(nameof(User.PhotoPath));// 执行删除操作，此操作会自动生成包含 RETURNING 子句的SQL脚本
// 在删除数据的同时，会将被删除记录的指定字段原始值返回
var count = this.DataAccess.Delete<User>(Condition.Equal(p => p.UserId, 100), // 删除条件：UserId 主键为 100 的用户options //传递删除选项，该选项指定了要返回的字段
);if (count > 0) // 如果成功删除了记录
{// 遍历所有被删除记录（此处为一条）的返回结果集foreach (var entry in options.Returning){// 从返回的原始数据中安全地尝试获取 PhotoPath 字段的值if (entry.TryGetValue<string>(nameof(User.PhotoPath), out var path) && !string.IsNullOrEmpty(path)){// 如果成功获取到非空路径，则执行文件清理等后续业务操作FileSystem.File.TryDelete(path);}}
}

说明

通过一个原子操作替代了传统的 “先查询，后删除” 两步操作，其开发友好性体现在：

原子性与一致性： 有效避免了在两次独立数据库操作之间，数据状态可能被其他并发操作修改而导致的业务逻辑错误，保证了操作的原子性和数据的一致性。
代码简洁性与性能： 显著减少了数据库的往返次数，简化了代码逻辑，一次操作即可完成所有任务，提升了执行效率。
意图清晰与可维护性： 通过声明式的 Return 方法，代码的意图（需要获取被删除数据的某个原始值）一目了然，极大地增强了代码的可读性和可维护性。