PostgreSQL 18 核心新特性深度解析：从异步 I/O 到时态约束，为现代硬件重写性能基因

前言

2026 年 7 月，PostgreSQL 全球开发组正式发布了 PostgreSQL 18。作为近年来改动幅度最大的一个版本，PostgreSQL 18 不是在原有框架上修修补补，而是从内核 I/O 子系统到查询优化器，从身份认证到数据类型，全方位针对现代硬件（NVMe SSD、多核 CPU、云原生环境）和现代应用场景（微服务、高并发、海量数据）做了一次深度重构。

笔者从 PostgreSQL 9.x 开始跟到现在，亲历了每一次大版本升级。这一次的感觉格外不同：几个核心改动——异步 I/O、复合索引跳过扫描、虚拟生成列、原生 OAuth 2.0 认证、UUIDv7——每一个单独拎出来都够写一篇文章，但 PostgreSQL 18 把它们打包在一起，形成了一套完整的能力升级闭环。

本文不报菜名，带你逐个深度拆解这些特性的底层原理、性能影响边界，以及在真实业务场景中的落地姿势。

一、异步 I/O：给数据库装上「流水线」引擎

1.1 同步 I/O 的历史包袱

在 PostgreSQL 18 之前，数据库与磁盘的交互基本上是「同步阻塞」模式：进程发起一个读请求，等待磁盘返回数据，然后才能继续处理下一个请求。这在机械硬盘时代问题不大——机械硬盘的随机访问延迟在毫秒级，顺序读带宽也有限，即使并发发出多个请求，实际收益也有限。

但到了 NVMe SSD 时代，情况完全变了。一块企业级 NVMe SSD 的随机读延迟已经低至几十微秒，顺序读带宽轻松突破数 GB/s。此时如果还沿用同步 I/O 模式，CPU 大量的时间被白白浪费在「等待」上，NVMe SSD 的高并发能力完全发挥不出来。

1.2 异步 I/O 的底层原理

PostgreSQL 18 引入了异步 I/O（AIO）子系统，其核心思想是：将 I/O 请求批量提交给操作系统内核，由内核在后台完成数据传输，数据库进程继续处理其他任务，等数据就绪后再回来取。

这背后的技术基础是 Linux 的 io_submit 系统调用（libaio）以及 io_uring 接口。PostgreSQL 18 可以选择使用其中任意一种：

# postgresql.conf 配置示例
io_method = 'io_uring'          # 推荐使用 io_uring（性能最优）
# io_method = 'libaio'         # 备选方案
effective_io_concurrency = 32   # 允许同时进行的异步 I/O 请求数

io_uring 是 Linux 5.1 引入的高性能 I/O 接口，相比传统的 libaio，它的优势在于：

• 零拷贝：通过共享内存的 ring buffer 传递 I/O 描述符，避免了内核态与用户态之间的数据拷贝
• 批量化：一次系统调用可以提交多个 I/O 请求，大幅减少系统调用开销
• 轮询模式：在高频 I/O 场景下，可以让应用进程轮询 I/O 完成情况，避免内核中断带来的上下文切换开销

1.3 性能实测：3 倍提升不是营销数字

这不是营销话术。PostgreSQL 官方基准测试团队使用 TPC-H 200GB 数据集，在配备 NVMe SSD 的服务器上做了对比：

从数据可以看出，异步 I/O 对顺序读场景的收益最为显著（3-4 倍），对随机读的提升相对有限（1.3 倍）。这符合预期：异步 I/O 的核心价值在于让批量顺序 I/O 流水线化，而 NVMe SSD 的顺序带宽远高于随机 I/O 带宽。

1.4 适用场景与注意事项

最值得开启的场景：

• 数据仓库、OLAP 查询（大量全表扫描、聚合）
• ETL 数据导入（C COPY、pg_dump 恢复）
• VACUUM FULL 和索引重建
• 日志分析系统（时序数据批量写入）

不适用或收益有限的场景：

• 以点查询为主的 OLTP 系统（随机读为主，异步收益有限）
• 数据量小于内存大小的热数据场景（直接走 shared_buffer，不落盘）

重要配置建议：

-- 查看当前 AIO 配置状态
SHOW effective_io_concurrency;
SHOW io_method;

-- 生产环境建议值（基于 SSD 性能调整）
-- 入门级 NVMe: effective_io_concurrency = 16
-- 企业级 NVMe: effective_io_concurrency = 64~128
-- 关注 io_uring 支持情况（Linux 5.1+）

二、复合索引跳过扫描：解放「被封印」的索引

2.1 索引设计者的噩梦

做数据库应用开发的同学，一定遇到过这种纠结：有一张用户行为表 user_events，常用查询模式包括：

-- 模式 A
SELECT * FROM user_events WHERE city = '北京' AND gender = '女';

-- 模式 B  
SELECT * FROM user_events WHERE gender = '女' AND age > 25;

-- 模式 C
SELECT * FROM user_events WHERE city = '北京' AND age > 25;

为了覆盖这些查询，你需要创建什么索引？

选项 1： 三个单列索引

CREATE INDEX idx_city ON user_events(city);
CREATE INDEX idx_gender ON user_events(gender);
CREATE INDEX idx_age ON user_events(age);

缺点：索引数量多，维护成本高，查询时需要回表。

选项 2： 复合索引

CREATE INDEX idx_city_gender_age ON user_events(city, gender, age);

缺点：只要查询条件里没有 city（最左前缀列），这个索引就完全用不上，只能退化到全表扫描。

这就是 PostgreSQL（以及其他关系型数据库）长期存在的「复合索引困境」：复合索引只能服务于以最左前缀列开头的查询。

2.2 跳过扫描的工作原理

PostgreSQL 18 的复合索引跳过扫描（Index Skip Scan）彻底打破了这条铁律。来看一个典型场景：

-- 查询条件不包含最左前缀列 city
SELECT * FROM user_events 
WHERE gender = '女' AND age > 25;

在没有 Skip Scan 的情况下，PostgreSQL 17 只能选择：① 使用 gender 单列索引，然后回表过滤 age > 25；② 直接全表扫描。

有了 Skip Scan，PostgreSQL 18 的执行计划完全不同：

Index Skip Scan on user_events using idx_city_gender_age
  (city 是低基数列，只有 ~10 个不同值)
  -> 5 次小范围索引扫描，每次扫描 city='不同值' 的子集

原理： PostgreSQL 18 会识别出「最左前缀列的基数较小」这个事实，然后采用如下策略：

1. 先找出最左前缀列（city）的所有不同值（通过索引本身就可以枚举，无需全表扫描）
2. 对每个 city 值，构造一个范围扫描：city = '该值' AND gender = '女' AND age > 25
3. 将这 N 次小范围扫描的结果合并

2.3 性能对比实测

在 PostgreSQL 18 的官方测试中，使用一个 5000 万行的表：

-- 测试表结构
CREATE TABLE events (
    id BIGSERIAL PRIMARY KEY,
    city VARCHAR(20),      -- 低基数，约 10 个不同值
    gender CHAR(1),        -- {M, F}
    age INT,
    event_type VARCHAR(50),
    created_at TIMESTAMP
);

CREATE INDEX idx_city_gender_age ON events(city, gender, age);

-- 测试查询（不含最左前缀列 city）
EXPLAIN ANALYZE 
SELECT * FROM events WHERE gender = 'F' AND age > 30;

18 倍的性能差距，核心原因是：跳过扫描只需要遍历索引本身（10 个城市 × 少量数据），而不需要扫描 5000 万行数据。

2.4 使用条件与限制

Skip Scan 不是万能药，它有明确的适用条件：

-- ✅ 触发条件：最左前缀列是低基数列（不同值数量少）
-- 一般经验：不同值 < 1000 时收益明显

-- ⚠️ 不触发的情况：最左前缀列基数过高
-- 如果 city 有 10000 个不同值，Skip Scan 可能比全表扫描更慢

-- ✅ 最佳实践：在高频查询中识别低基数列，将其放在复合索引的最左位置
-- 利用 Skip Scan，一个复合索引可以服务多种查询模式

工程建议： 在 PostgreSQL 18 环境下，可以用 EXPLAIN (ANALYZE, BUFFERS) 检查执行计划是否用上了 Skip Scan：

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT * FROM events WHERE gender = 'F' AND age > 30;
-- 查找输出中是否包含 "Index Skip Scan"

三、虚拟生成列：计算换空间的新哲学

3.1 存储型生成列的历史问题

生成列（Generated Columns）是 Postgre 12 引入的特性，允许在表定义中声明一个列的值由其他列计算而来：

CREATE TABLE orders (
    unit_price NUMERIC(10, 2),
    quantity INT,
    tax_rate NUMERIC(4, 4),
    -- 生成列：订单总价（含税）
    total_price NUMERIC(12, 2) GENERATED ALWAYS AS (
        unit_price * quantity * (1 + tax_rate)
    ) STORED
);

注意这里的 STORED 关键字——在 PostgreSQL 17 及之前，生成列默认就是 STORED（存储型），即：每次 INSERT/UPDATE 时，数据库会计算生成列的值，并将其物理写入磁盘。

这带来了两个问题：

空间开销： 如果生成列基于大文本字段计算，存储开销会急剧增加。

维护负担： 当生成列的计算表达式需要修改时，必须重写整个表（ALTER TABLE）：

-- PostgreSQL 17：修改生成列表达式需要重写表
ALTER TABLE orders 
ALTER COLUMN total_price 
GENERATED ALWAYS AS (unit_price * quantity * (1 + tax_rate + discount_rate)) STORED;
-- ⚠️ 耗时：对于大表可能需要数小时

3.2 虚拟生成列：按需计算的优雅解法

PostgreSQL 18 将生成列的默认值从 STORED 改为 VIRTUAL（虚拟型）：

-- PostgreSQL 18：默认即为 VIRTUAL，查询时计算，不占磁盘空间
CREATE TABLE orders (
    unit_price NUMERIC(10, 2),
    quantity INT,
    tax_rate NUMERIC(4, 4),
    discount_rate NUMERIC(4, 4),
    -- 默认 VIRTUAL：只在查询时计算，不存储
    total_price NUMERIC(12, 2) GENERATED ALWAYS AS (
        unit_price * quantity * (1 + tax_rate)
    ) VIRTUAL
);

-- 如果确实需要存储型，明确指定 STORED
CREATE TABLE products (
    base_price NUMERIC(10, 2),
    tax_rate NUMERIC(4, 4),
    -- 存储型：适合计算量大的场景，换取查询性能
    final_price NUMERIC(12, 2) GENERATED ALWAYS AS (
        base_price * (1 + tax_rate)
    ) STORED
);

3.3 虚拟 vs 存储：选型决策树

查询频率高 + 计算简单 → VIRTUAL（节省空间，读取略慢）
查询频率高 + 计算复杂 → STORED（预计算省 CPU，读取快）
数据量大 + 写入频繁 → VIRTUAL（减少写入 I/O）
写入少 + 查询极频繁 → STORED（最大化查询性能）

3.4 实战：迁移现有生成列

如果你在 PostgreSQL 17 中已经创建了存储型生成列，升级到 PostgreSQL 18 后，可以考虑将其改为虚拟型以节省空间：

-- 查看当前生成列类型
SELECT 
    attname AS column_name,
    attgenerated AS generation_type
FROM pg_attribute
WHERE attrelid = 'orders'::regclass
  AND attgenerated != '0';

-- 将 STORED 改为 VIRTUAL（不重写表，即时完成）
ALTER TABLE orders 
ALTER COLUMN total_price SET DATA TYPE NUMERIC(12, 2)
GENERATED ALWAYS AS (unit_price * quantity * (1 + tax_rate)) VIRTUAL;
-- ✅ 在 PostgreSQL 18 中，这是即时元数据操作，不重写表

四、UUIDv7：时间有序的新一代唯一标识符

4.1 UUIDv4 的性能问题

大多数应用在需要全局唯一 ID 时，会选择 UUIDv4（随机 UUID）。UUIDv4 的优点是生成简单、碰撞概率极低，但缺点也很明显：

索引效率低下： UUIDv4 的 128 位中没有时间信息，数据在 B-tree 索引中是随机分布的。新插入的行会随机分布在 B-tree 的各个位置，导致：

• 写入放大：每次插入都可能触发 B-tree 节点分裂，产生大量磁盘 I/O
• 页面填充率低：新行插入到随机位置，导致数据页填充率只有 20-30%，空间浪费严重
• 缓存效率差：热数据分散在大量数据页中，缓存命中率低

-- 使用 UUIDv4 的索引效率问题
CREATE TABLE events_v4 (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    payload JSONB
);

-- 100 万行后，B-tree 页面填充率只有约 25%
-- 索引体积臃肿，随机 I/O 导致查询性能不稳定

4.2 UUIDv7 的结构与优势

UUIDv7（RFC draft）将 128 位做了重新设计：

+-----------------------------------------------------------------------+
|                   UUIDv7 字节布局（RFC draft）                        |
+-----------------------------------------------------------------------+
|  48 bits: Unix Epoch timestamp (毫秒)                                 |
|   4 bits: version = 7                                                |
|  12 bits: 毫秒级细粒度序列号（防止同一毫秒内重复）                      |
|  38 bits: random                                                     |
|   6 bits: variant = 0b10xxxx                                         |
|  26 bits: random                                                     |
+-----------------------------------------------------------------------+

核心优势：时间有序。 因为高位是时间戳，UUIDv7 的值随时间单调递增，插入 B-tree 时始终追加到末尾，不会触发节点分裂：

-- PostgreSQL 18 原生支持 uuidv7()
CREATE EXTENSION IF NOT EXISTS "pg_uuidv7";

-- 使用新的 uuidv7() 函数生成时间有序 UUID
CREATE TABLE events_v7 (
    id UUID DEFAULT uuidv7() PRIMARY KEY,
    payload JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 插入 100 万行后，页面填充率可达 85-95%
-- B-tree 高度降低，查询和写入性能显著提升

4.3 与其他时间有序 ID 方案的对比

PostgreSQL 18 的 uuidv7() 实现了 draft RFC 的全部要求，并额外支持 min_uuidv7(time) 和 max_uuidv7(time) 函数，可以根据指定时间生成该时间范围内的最小/最大 UUID：

-- 查询某个时间范围内的所有记录（利用 B-tree 范围扫描）
SELECT * FROM events_v7 
WHERE id BETWEEN min_uuidv7('2026-07-01'::timestamptz) 
             AND max_uuidv7('2026-07-31'::timestamptz)
ORDER BY created_at;

五、原生 OAuth 2.0 认证：数据库融入现代身份体系

5.1 传统认证方式的局限性

在 PostgreSQL 17 及之前，数据库认证主要依赖：

• md5：密码摘要，可被彩虹表攻击
• scram-sha-256：当前推荐，但需要独立管理密码
• peer/ident：依赖操作系统用户，只能用于本地连接
• gssapi/sspi：Kerberos 认证，企业 AD 集成复杂

随着微服务架构和无服务器（Serverless）技术的普及，应用的身份认证越来越多地交给了专业的身份提供商（IdP）：Keycloak、Auth0、Okta、各大云平台的 IAM。这些系统都基于 OAuth 2.0/OIDC 标准。

问题： 在 PostgreSQL 17 及之前，让数据库接入这些现代身份体系，需要自行开发认证中间件，或者使用 pgbouncer 等连接池工具做认证代理。配置复杂，维护成本高。

5.2 PostgreSQL 18 的 OAuth 2.0 原生支持

PostgreSQL 18 提供了原生的 OAuth 2.0 认证支持，架构简洁清晰：

# postgresql.conf 配置 OAuth 验证器
oauth_validator_libraries = '/usr/lib/postgresql/oauth2_validator.so'
oauth_validator_discovery_url = 'https://your-idp.com/.well-known/openid-configuration'
oauth_validator_client_id = 'postgresql-service'

# pg_hba.conf 使用 oauth 认证方法
# TYPE  DATABASE  USER     ADDRESS           METHOD
host   all       all      10.0.0.0/8        oauth
host   all       readonly 0.0.0.0/0         oauth

5.3 认证流程解析

客户端                          PostgreSQL                    身份提供商(IdP)
  |                                  |                               |
  |-- [OAuth Token] ---------------->|                               |
  |                                  |-- 验证 Token ------------------>|
  |                                  |                               |
  |                                  |<-- Token 有效 + Claims --------|
  |                                  |                               |
  |                                  |--- 映射到数据库角色 ------------|
  |<-- 连接建立（数据库会话） ---------|                               |

1. 客户端持有从 IdP 获取的 OAuth 2.0 Access Token
2. PostgreSQL 使用配置的验证器库向 IdP 验证 Token 有效性
3. 从 Token 的 Claims 中提取用户名、角色组信息
4. 通过 pg_hba.conf 中的映射规则，将 OAuth 角色映射到数据库角色（可支持组）

5.4 角色映射与最小权限

-- 基于 OAuth Claims 动态映射数据库角色
-- 需要在 postgresql.conf 中配置映射规则
-- oauth_role_mapping = 'engineer->readwrite, analyst->readonly'

-- 实际效果：
-- OAuth Token 包含 role="engineer" → 映射到数据库 readwrite 角色
-- OAuth Token 包含 role="analyst"  → 映射到数据库 readonly 角色

-- 结合行级安全（RLS）实现列级/行级权限控制
ALTER TABLE customer_data ENABLE ROW LEVEL SECURITY;
CREATE POLICY analyst_can_see_dept ON customer_data
    FOR SELECT USING (
        current_setting('oauth.department') = department
    );

六、时态约束：数据合法性的守护者

6.1 业务数据的时间合法性问题

在许多业务场景中，数据存在「有效时间」的概念：

-- 员工任职记录
CREATE TABLE employee_positions (
    employee_id INT,
    department VARCHAR(50),
    position VARCHAR(50),
    start_date DATE,
    end_date DATE  -- NULL 表示当前在职
);

-- 业务规则：某员工在同一时间段内只能有一个职位
-- 传统做法：应用层检查或触发器，复杂且容易出错

PostgreSQL 18 引入了**排他约束（Exclusion Constraints）**对时间类型的增强支持，可以声明式地表达时间互斥规则：

-- 声明：同一员工在重叠时间段内不能有两个职位
CREATE TABLE employee_positions (
    employee_id INT,
    department VARCHAR(50),
    position VARCHAR(50),
    period DATERANGE,
    EXCLUDE USING gist (
        employee_id WITH =,
        period WITH &&
    )
);

-- 测试：正常插入
INSERT INTO employee_positions VALUES (
    1001, '研发部', '工程师', 
    daterange('2026-01-01', '2026-07-01')
);
-- ✅ 成功

-- 测试：重叠时间段插入
INSERT INTO employee_positions VALUES (
    1001, '产品部', '产品经理', 
    daterange('2026-06-01', '2026-12-31')  -- 与上面的 2026-01-01~2026-07-01 重叠
);
-- ❌ 错误：排他约束 violation
-- ERROR: conflicting key value violates exclusion constraint

6.2 与 PERIOD 语法的配合

PostgreSQL 18 进一步完善了 SQL:2011 标准中的 PERIOD 语法，支持更直观的时间范围定义：

-- 使用 PERIOD 声明表的时间维度
CREATE TABLE insurance_policies (
    policy_id BIGSERIAL,
    holder_name VARCHAR(100),
    coverage_amount NUMERIC(12, 2),
    POLICY PERIOD FOR policy_period (start_date, end_date)
) WITH (system_time_period_name = 'policy_period');

-- SYSTEM_TIME 语法支持 point-in-time 查询（闪回查询）
SELECT * FROM insurance_policies
    FOR SYSTEM_TIME AS OF TIMESTAMP '2026-07-01 00:00:00';

七、升级策略与生产环境避坑

7.1 原地升级（pg_upgrade）加速

PostgreSQL 18 对 pg_upgrade 做了大幅优化：

• 并行索引重建：pg_upgrade 现在可以并行重建索引，大幅缩短升级时间
• 改进的连接重定向：减少了升级后首次查询的延迟（原来需要重建共享内存中的 catalog cache）

# 推荐升级命令（PostgreSQL 18）
pg_upgrade \
    --old-datadir=/var/lib/postgresql/17/data \
    --new-datadir=/var/lib/postgresql/18/data \
    --old-bindir=/usr/lib/postgresql/17/bin \
    --new-bindir=/usr/lib/postgresql/18/bin \
    --jobs=8 \        # 8 个并行任务（根据 CPU 核心数调整）
    --link           # 硬链接模式，速度快但需小心旧集群目录

7.2 配置参数变更提醒

7.3 回归测试清单

升级前务必执行回归测试：

-- 1. 检查慢查询执行计划变化
SELECT query, calls, mean_time 
FROM pg_stat_statements 
ORDER BY mean_time DESC 
LIMIT 20;

-- 2. 验证生成列表达式计算结果一致性
-- （STORED → VIRTUAL 可能影响浮点计算时机）
SELECT id, col_a, col_b, generated_col 
FROM test_table 
WHERE abs(generated_col - computed_value) > 0.0001;

-- 3. 检查 OAuth 认证配置
SELECT * FROM pg_hba_file_rules 
WHERE auth_method = 'oauth';

-- 4. 监控 AIO 使用情况（pg_stat_bgwriter）
SELECT * FROM pg_stat_bgwriter;

八、性能优化综合实战

8.1 混合场景优化配置模板

针对典型的 Web 应用混合负载（OLTP 查询 + 报表分析）：

# postgresql.conf - PostgreSQL 18 混合负载优化配置

# === I/O 子系统（PostgreSQL 18 新增）===
io_method = 'io_uring'
effective_io_concurrency = 64

# === 内存配置 ===
shared_buffers = '32GB'              # 建议为系统内存的 1/4
effective_cache_size = '96GB'        # 建议为系统内存的 3/4
work_mem = '64MB'
maintenance_work_mem = '2GB'

# === 并发控制 ===
max_worker_processes = 16
max_parallel_workers_per_gather = 8
max_parallel_workers = 16

# === 写入优化 ===
wal_buffers = '64MB'
min_wal_size = '4GB'
max_wal_size = '16GB'

# === 日志与监控 ===
log_min_duration_statement = 1000   # 记录超过 1s 的查询
pg_stat_statements.max = 10000

8.2 性能监控仪表盘关键指标

使用 PostgreSQL 18 后，以下指标值得重点关注：

-- AIO 使用效率监控
SELECT 
    name, 
    setting,
    current_setting(name) AS current_value
FROM pg_settings
WHERE name IN (
    'io_method', 
    'effective_io_concurrency'
);

-- 复合索引 Skip Scan 使用情况
SELECT 
    schemaname,
    tablename,
    indexname,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch
FROM pg_stat_user_indexes
WHERE idx_scan > 0
ORDER BY idx_tup_read DESC
LIMIT 20;

-- 生成列存储类型检查
SELECT 
    attrelid::regclass AS table_name,
    attname AS column_name,
    CASE attgenerated 
        WHEN 's' THEN 'STORED' 
        WHEN 'v' THEN 'VIRTUAL' 
        ELSE 'NOT_GENERATED' 
    END AS generation_type
FROM pg_attribute
WHERE attnum > 0
  AND attrelid IN (
      SELECT oid FROM pg_class 
      WHERE relkind = 'r'
  )
  AND attgenerated != '0';

九、总结：PostgreSQL 18 的工程哲学

回顾 PostgreSQL 18 的这些改动，能清晰地看到一条主线：让数据库与硬件现实和解。

• NVMe SSD 的高带宽 → 异步 I/O 让数据库不再被同步 I/O 绑架
• 现代云原生架构 → OAuth 2.0 让数据库自然融入 SSO 体系
• AI 时代的 ID 需求 → UUIDv7 兼顾唯一性、分布式和 B-tree 友好性
• 复杂查询模式 → Skip Scan 解放了复合索引的生产力
• 资源成本压力 → 虚拟生成列让存储和计算各司其职

这不是一场激进的重写，而是一次精准的能力升级。每一个新特性都有明确的适用边界，文档也写得很清楚「这个特性在 X 场景下收益最大，在 Y 场景下可能无效」。

对于已经在使用 PostgreSQL 的团队，笔者的建议是：先在测试环境把异步 I/O 跑通，这是收益最确定、风险最低的改动。然后根据业务特点，选择性启用 UUIDv7（如果是 ID 生成密集型应用）和虚拟生成列（如果有大文本计算列）。OAuth 2.0 和时态约束属于锦上添花，按需引入。

标签： PostgreSQL|数据库|性能优化|异步I/O|索引优化|UUIDv7|OAuth认证|生成列

关键词： PostgreSQL 18|异步I/O|Index Skip Scan|虚拟生成列|Uuidv7|OAuth 2.0|时态约束|数据库性能|NVMe优化|pg_upgrade