PostgreSQL 18 技术内幕：AIO 异步框架与跳跃式扫描带来的性能革命

PostgreSQL 18 已于 2025 年 9 月正式发布，这是世界上最先进的开源数据库的又一个重要里程碑。新版本引入了全新的异步 I/O 子系统，从存储读取时性能提升高达 3 倍，同时带来了虚拟生成列、UUIDv7、跳跃式扫描、OAuth 2.0 认证等重大特性更新。本文将深入剖析这些核心改进的技术细节，并提供完整的实战代码示例。

一、异步 I/O 框架：打破同步阻塞的性能瓶颈

1.1 为什么需要异步 I/O

传统 PostgreSQL 采用同步 I/O 模型，当查询需要从磁盘读取数据时，CPU 必须等待 I/O 操作完成才能继续执行。这种阻塞式模型在本地存储上问题不大，但在云存储场景下，网络延迟使得单次 I/O 等待时间显著增加，严重制约了查询性能。

PostgreSQL 18 引入的异步 I/O（AIO）框架彻底改变了这一局面。新机制允许在等待 I/O 完成时继续推进其他工作，实现了真正的并行预读，将读取密集型查询的性能提升 2-3 倍。

1.2 三种 I/O 实现方式

PostgreSQL 18 提供了三种异步 I/O 后端实现：

worker 模式：使用若干后台 I/O worker 进程接收处理后端进程的 I/O 请求，适合所有平台。

io_uring 模式：利用 Linux 内核的 io_uring 子系统，通过操作系统内核线程处理 I/O 请求，性能最佳但需要较新的 Linux 内核（5.1+）。

sync 模式：满足异步 I/O 框架接口要求的同步 I/O，作为兜底方案。

# postgresql.conf 配置示例

# I/O 方法选择
io_method = io_uring  # worker, io_uring, sync

# 并发控制
effective_io_concurrency = 300    # 1-1000
maintenance_io_concurrency = 300  # 维护操作并发
io_max_concurrency = 128          # 单进程最大并发 I/O

# 合并读写
io_combine_limit = 256kB          # 合并读写上限
io_max_combine_limit = 256kB      # 启动时上限

1.3 异步 I/O 实战配置

让我们通过一个完整的配置示例来启用异步 I/O：

-- 查看当前 I/O 配置
SHOW io_method;
SHOW io_max_concurrency;

-- 监控异步 I/O 状态
SELECT * FROM pg_aios LIMIT 5;

pg_aios 视图提供了异步 I/O 的实时监控数据：

-[ RECORD 1 ]---+-------------------------------------------
pid             | 85834
io_id           | 14208
io_generation   | 204
state           | SUBMITTED
operation       | readv
off             | 116252672
length          | 8192
target          | smgr
target_desc     | block 14191 in file "base/5/16427"

1.4 性能基准测试

为了验证异步 I/O 的实际效果，我们进行了详细的性能测试：

测试环境：

• 云服务器：AWS r6g.2xlarge（8 vCPU, 64GB RAM）
• 存储：gp3 卷，16000 IOPS
• 数据规模：100GB 表，1 亿行数据

-- 创建测试表
CREATE TABLE benchmark_data (
    id SERIAL PRIMARY KEY,
    category INT NOT NULL,
    value NUMERIC(15,2),
    created_at TIMESTAMP DEFAULT NOW()
) WITH (fillfactor=80);

-- 插入 1 亿条测试数据
INSERT INTO benchmark_data (category, value)
SELECT 
    (random() * 1000)::int,
    (random() * 1000000)::numeric(15,2)
FROM generate_series(1, 100000000);

-- 分析表
ANALYZE benchmark_data;

测试查询：

-- 大表顺序扫描
EXPLAIN (ANALYZE, BUFFERS, TIMING) 
SELECT category, AVG(value), COUNT(*)
FROM benchmark_data
WHERE value > 500000
GROUP BY category;

结果对比：

异步 I/O 模式下，查询性能提升约 2.5 倍，云存储环境下优势更加明显。

1.5 内部架构解析

PostgreSQL 18 的异步 I/O 框架采用了精巧的设计：

PgAioHandle 结构：每个异步 I/O 操作通过句柄管理，包含操作类型、目标对象、回调函数等。句柄在共享内存中预分配，通过 generation 号标记复用。

回调机制：通过 PgAioHandleCallbacks 结构实现多态，支持不同 I/O 目标（当前是 smgr，未来计划支持 WAL）。

ReadStream 改造：原有的 ReadStream 接口被改造为异步模式，实现真正的并行预读：

// 简化的 ReadStream 异步读取伪代码
Buffer ReadStreamNextBlock(ReadStream *stream) {
    if (stream->pending_aio != NULL) {
        // 等待当前异步 I/O 完成
        WaitForAioCompletion(stream->pending_aio);
    }
    
    // 发起下一批异步预读
    for (int i = 0; i < io_concurrency; i++) {
        SubmitAsyncRead(stream, next_block+i);
    }
    
    return stream->current_buffer;
}

1.6 使用注意事项

1. 内核版本要求：io_uring 需要 Linux 5.1+ 内核，推荐 5.10+ 以获得最佳性能和稳定性。

2. 资源消耗：异步 I/O 需要额外的共享内存，io_max_concurrency 设置过大可能导致数据库启动失败。

3. 当前限制：PostgreSQL 18 仅实现了异步读取，异步写入功能仍在开发中。

4. 监控与调优：定期检查 pg_stat_io 和 pg_aios 视图，根据实际负载调整并发参数。

二、跳跃式扫描：让 B 树索引突破前导列限制

2.1 问题背景

在 PostgreSQL 17 及之前版本中，多列 B 树索引的效率高度依赖于"最左前缀"原则。对于一个 (a, b, c) 上的索引：

• WHERE a = 5 → 索引高效
• WHERE a = 5 AND b = 10 → 索引高效
• WHERE b = 10 → 必须全索引扫描，通常选择顺序扫描

这种限制导致即使存在合适的索引，查询优化器也可能被迫选择低效的执行计划。

2.2 Skip Scan 原理

PostgreSQL 18 引入的跳跃式扫描（Skip Scan）通过动态生成等式约束，实现了对非前导列的高效索引访问。

核心思想：对于 WHERE b = 10 查询，系统自动遍历索引第一列 a 的所有不同值，对每个值执行一次索引查找：

索引结构：(a, b) -> 
(1, 5), (1, 10), (1, 15),
(2, 8), (2, 10), (2, 20),
(3, 10), (3, 25),
...

WHERE b = 10 的执行过程：
1. 定位到 a=1 的第一个 b=10
2. 跳到 a=2，定位 b=10
3. 跳到 a=3，定位 b=10
...

2.3 性能对比测试

-- 创建测试表和索引
CREATE TABLE t1 (
    c1 int,
    c2 int,
    c3 float
) WITH (fillfactor=80);

CREATE INDEX idx_t1_c1c2 ON t1(c1, c2);

-- 插入 100 万行数据
INSERT INTO t1
SELECT 
    (random()*1000)::int, 
    (random()*10000)::int, 
    random()
FROM generate_series(1, 1000000) g;

ANALYZE t1;

PostgreSQL 17 执行计划：

EXPLAIN ANALYZE SELECT * FROM t1 WHERE c2=100;

QUERY PLAN
---------------------------------------------------------
Gather  (cost=1000.00..12986.33 rows=100 width=16) 
        (actual time=1.125..76.076 rows=90 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  ->  Parallel Seq Scan on t1  (cost=0.00..11976.33 rows=42 width=16)
        Filter: (c2 = 100)
        Rows Removed by Filter: 333303
Planning Time: 0.792 ms
Execution Time: 76.165 ms

PostgreSQL 18 执行计划：

QUERY PLAN
---------------------------------------------------------
Index Scan using idx_t1_c1c2 on t1  (cost=0.42..3900.84 rows=100 width=16)
        (actual time=0.225..11.464 rows=90 loops=1)
  Index Cond: (c2 = 100)
  Index Searches: 1002
Planning Time: 0.141 ms
Execution Time: 11.522 ms

性能从 76ms 提升到 11.5ms，提升约 6.6 倍！

2.4 适用场景分析

跳跃式扫描特别适合以下场景：

1. 低基数前导列：前导列的不同值数量较少（如状态码、类型字段），跳跃次数有限。

2. 高选择性查询：查询条件选择性高，最终匹配行数少。

3. 覆盖索引优化：查询列都在索引中，避免回表。

-- 最佳实践：为常见查询模式设计索引
CREATE INDEX idx_orders_status_date_amount 
ON orders(status, order_date, amount);

-- 场景1：查询特定日期的订单（跳过 status）
SELECT * FROM orders WHERE order_date = '2026-01-15';
-- Skip Scan 会遍历所有 status 值

-- 场景2：查询特定金额范围（跳过 status 和 order_date）
SELECT * FROM orders WHERE amount > 10000;
-- Skip Scan 会遍历所有 (status, order_date) 组合

2.5 当前限制

• 仅支持等值比较条件，范围查询暂不支持
• 前导列基数过高时，跳跃开销可能超过收益
• 需要统计信息准确，否则优化器可能选择错误的计划

三、虚拟生成列：存储与计算的灵活平衡

3.1 功能概述

PostgreSQL 18 终于引入了期待已久的虚拟生成列（Virtual Generated Column）。与存储生成列不同，虚拟列不占用物理存储空间，其值在查询时实时计算。

存储生成列 vs 虚拟生成列：

3.2 实战示例

-- 创建包含虚拟列的产品表
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    price NUMERIC(10,2) NOT NULL,
    tax_rate NUMERIC(5,2) DEFAULT 0.20,
    
    -- 虚拟列：含税价格
    price_with_tax NUMERIC(10,2) 
        GENERATED ALWAYS AS (price * (1 + tax_rate)) VIRTUAL,
    
    -- 存储列：创建时间戳快照
    created_month INT 
        GENERATED ALWAYS AS (EXTRACT(MONTH FROM NOW())::int) STORED
);

-- 插入数据（无需指定生成列）
INSERT INTO products (name, price, tax_rate) 
VALUES 
    ('Laptop', 1000.00, 0.20),
    ('Phone', 699.99, 0.18),
    ('Tablet', 499.00, 0.15);

-- 查询结果
SELECT name, price, tax_rate, price_with_tax FROM products;

  name  |  price  | tax_rate | price_with_tax 
--------+---------+----------+----------------
 Laptop | 1000.00 |     0.20 |        1200.00
 Phone  |  699.99 |     0.18 |         825.99
 Tablet |  499.00 |     0.15 |         573.85

3.3 虚拟列的高级应用

场景1：计算派生字段

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    birth_date DATE,
    hire_date DATE,
    base_salary NUMERIC(10,2),
    
    -- 虚拟列：全名
    full_name VARCHAR(101) 
        GENERATED ALWAYS AS (first_name || ' ' || last_name) VIRTUAL,
    
    -- 虚拟列：年龄
    age INT 
        GENERATED ALWAYS AS (
            EXTRACT(YEAR FROM AGE(NOW(), birth_date))::int
        ) VIRTUAL,
    
    -- 虚拟列：司龄
    years_of_service INT 
        GENERATED ALWAYS AS (
            EXTRACT(YEAR FROM AGE(NOW(), hire_date))::int
        ) VIRTUAL,
    
    -- 虚拟列：年度总成本（含社保）
    annual_cost NUMERIC(12,2) 
        GENERATED ALWAYS AS (
            base_salary * 12 * 1.4  -- 假设社保系数 1.4
        ) VIRTUAL
);

-- 查询虚拟列
SELECT full_name, age, years_of_service, annual_cost 
FROM employees 
WHERE years_of_service > 5;

场景2：JSON 字段提取

CREATE TABLE api_logs (
    id SERIAL PRIMARY KEY,
    request_time TIMESTAMP DEFAULT NOW(),
    payload JSONB NOT NULL,
    
    -- 从 JSON 提取关键字段作为虚拟列
    user_id INT 
        GENERATED ALWAYS AS ((payload->>'user_id')::int) VIRTUAL,
    
    api_version VARCHAR(10) 
        GENERATED ALWAYS AS (payload->>'version') VIRTUAL,
    
    request_type VARCHAR(20) 
        GENERATED ALWAYS AS (payload->>'type') VIRTUAL
);

-- 可以直接在虚拟列上建索引（需表达式索引支持）
CREATE INDEX idx_api_logs_user_id ON api_logs(user_id);

-- 查询优化
SELECT * FROM api_logs WHERE user_id = 12345;

3.4 实现原理

虚拟列的元数据存储在 pg_attribute 系统表中，attgenerated 字段标识列类型：

• 's' = STORED（存储生成列）
• 'v' = VIRTUAL（虚拟生成列）

-- 查看虚拟列元数据
SELECT attname, attgenerated, pg_get_expr(adbin, adrelid) AS expression
FROM pg_attribute
JOIN pg_attrdef ON attrelid = adrelid AND attnum = adnum
WHERE attrelid = 'products'::regclass 
  AND attgenerated = 'v';

    attname     | attgenerated |           expression            
----------------+--------------+--------------------------------
 price_with_tax | v            | (price * (1 + tax_rate))

3.5 性能考虑

虚拟列虽然节省存储空间，但需要注意：

1. 计算开销：每次查询都需要重新计算，复杂表达式可能影响性能。

2. 索引策略：虚拟列上的索引需要存储计算结果，实际上相当于一个存储列。

3. 更新语义：虚拟列不能直接更新，必须通过修改其依赖的列间接更新。

四、UUIDv7：时间有序的全局唯一标识符

4.1 为什么选择 UUIDv7

传统 UUID v4 是完全随机的，在数据库中存在严重的性能问题：

• 索引碎片化：随机插入导致 B 树频繁分裂
• 缓冲区抖动：热点数据被频繁驱逐
• 写入性能下降：缺乏局部性，无法利用顺序 I/O

UUIDv7 解决了这些问题：它将 48 位 Unix 毫秒时间戳嵌入 UUID 开头，确保生成的时间顺序与存储顺序一致。

4.2 UUIDv7 结构

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          unix_ts_ms                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  var  |                       rand_b                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           rand_b                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 前 48 位：Unix 毫秒时间戳
• 版本位：4 位版本号（7）
• 变体位：2 位变体标识
• 其余位：随机数

4.3 PostgreSQL 18 中的 UUIDv7

-- 生成 UUIDv7
SELECT gen_random_uuidv7();

           gen_random_uuidv7            
--------------------------------------
 0192f0b8-3c7a-7c3e-8d2f-1a5b6c7d8e9f

创建使用 UUIDv7 作为主键的表：

-- 启用 uuid 扩展
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

-- 创建表
CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuidv7(),
    customer_id INT NOT NULL,
    total_amount NUMERIC(12,2),
    status VARCHAR(20) DEFAULT 'pending',
    created_at TIMESTAMP DEFAULT NOW()
);

-- 创建时间索引（UUIDv7 本身就有序，可以不建额外索引）
CREATE INDEX idx_orders_created ON orders(created_at);

-- 插入测试数据
INSERT INTO orders (customer_id, total_amount)
SELECT 
    (random() * 10000)::int,
    (random() * 5000)::numeric(12,2)
FROM generate_series(1, 100000);

-- UUIDv7 自动排序
SELECT id, created_at FROM orders ORDER BY id LIMIT 5;

                   id                   |     created_at      
----------------------------------------+---------------------
 0192f0b8-3c7a-7c3e-8d2f-1a5b6c7d8e9f | 2026-01-15 10:23:45
 0192f0b8-3c7a-7c3e-8d2f-1a5b6c7d8ea0 | 2026-01-15 10:23:45
 0192f0b8-3c7a-7c3e-8d2f-1a5b6c7d8ea1 | 2026-01-15 10:23:46
 0192f0b8-3c7a-7c3e-8d2f-1a5b6c7d8ea2 | 2026-01-15 10:23:46

4.4 性能对比：UUIDv4 vs UUIDv7

-- 创建两个测试表
CREATE TABLE orders_uuid4 (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    data TEXT
);

CREATE TABLE orders_uuid7 (
    id UUID PRIMARY KEY DEFAULT gen_random_uuidv7(),
    data TEXT
);

-- 性能测试
DO $$
DECLARE
    start_ts TIMESTAMP;
BEGIN
    -- UUIDv4 测试
    start_ts := clock_timestamp();
    INSERT INTO orders_uuid4 (data)
    SELECT md5(random()::text)
    FROM generate_series(1, 100000);
    RAISE NOTICE 'UUIDv4 insert time: %', clock_timestamp() - start_ts;
    
    TRUNCATE orders_uuid4;
    
    -- UUIDv7 测试
    start_ts := clock_timestamp();
    INSERT INTO orders_uuid7 (data)
    SELECT md5(random()::text)
    FROM generate_series(1, 100000);
    RAISE NOTICE 'UUIDv7 insert time: %', clock_timestamp() - start_ts;
END $$;

典型结果：

UUIDv4 insert time: 00:00:12.345
UUIDv7 insert time: 00:00:03.567

UUIDv7 的插入性能提升 3-4 倍，这是因为：

1. 顺序插入：减少 B 树分裂
2. 更好的缓存命中：热点页面集中
3. 更少的 WAL 日志：减少页面修改记录

五、OAuth 2.0 认证：企业级安全集成

5.1 功能概述

PostgreSQL 18 原生支持 OAuth 2.0 认证，使得数据库可以与企业单点登录（SSO）系统无缝集成，如 Okta、Azure AD、Keycloak 等。

5.2 配置示例

# pg_hba.conf 配置

# OAuth 2.0 认证
hostssl all all 0.0.0.0/0 oauth

# postgresql.conf 配置
oauth_issuer = 'https://your-identity-provider.com'
oauth_client_id = 'your-client-id'
oauth_client_secret = 'your-client-secret'
oauth_scope = 'openid profile email'

5.3 连接示例

import psycopg2
import requests

# 获取 OAuth token
def get_oauth_token():
    response = requests.post(
        'https://your-identity-provider.com/oauth/token',
        data={
            'grant_type': 'client_credentials',
            'client_id': 'your-client-id',
            'client_secret': 'your-client-secret',
            'scope': 'openid'
        }
    )
    return response.json()['access_token']

# 使用 token 连接 PostgreSQL
token = get_oauth_token()
conn = psycopg2.connect(
    host='localhost',
    database='mydb',
    user='oauth_user',
    password=token  # OAuth token 作为密码
)

5.4 安全优势

1. 集中身份管理：用户账号统一在 IdP 管理
2. 多因素认证：继承 IdP 的 MFA 能力
3. 细粒度授权：基于 OAuth scope 控制访问
4. 审计追踪：完整的认证日志

六、监控增强：更精细的可观测性

6.1 Per-Backend I/O 统计

PostgreSQL 18 新增 pg_stat_get_backend_io() 函数，提供每个后端进程的 I/O 统计：

SELECT 
    pid,
    backend_type,
    read_bytes,
    write_bytes,
    extend_bytes
FROM pg_stat_activity
JOIN pg_stat_get_backend_io(pid) ON true
ORDER BY read_bytes DESC
LIMIT 10;

 pid  |  backend_type   | read_bytes | write_bytes | extend_bytes 
------+-----------------+------------+-------------+--------------
 1234 | client backend  |   52428800 |    10485760 |      2097152
 1235 | autovacuum      |   31457280 |     5242880 |      1048576
 1236 | background worker|  10485760 |     2097152 |       524288

6.2 VACUUM/ANALYZE 延迟统计

-- 查看表的 VACUUM 时间统计
SELECT 
    schemaname,
    tablename,
    total_vacuum_time,
    total_autovacuum_time,
    total_analyze_time
FROM pg_stat_all_tables
ORDER BY total_vacuum_time DESC
LIMIT 10;

6.3 检查点统计增强

SELECT 
    num_timed,
    num_requested,
    num_done,
    slru_written
FROM pg_stat_checkpointer;

新增 num_done 列显示实际完成的检查点数量，slru_written 显示 SLRU 缓冲区写入量。

七、升级指南与最佳实践

7.1 升级前准备

# 备份数据
pg_dump -Fc mydb > mydb_backup.dump

# 检查扩展兼容性
psql -c "SELECT * FROM pg_extension;"

# 运行 pg_upgrade --check
/usr/lib/postgresql/18/bin/pg_upgrade \
  --old-bindir /usr/lib/postgresql/17/bin \
  --new-bindir /usr/lib/postgresql/18/bin \
  --old-datadir /var/lib/postgresql/17/main \
  --new-datadir /var/lib/postgresql/18/main \
  --check

7.2 主要版本升级优化

PostgreSQL 18 改进了主要版本升级机制：

• 增量升级：减少升级停机时间
• 快速性能恢复：升级后性能更快达到预期
• 破坏性变更处理：更清晰的升级路径

7.3 异步 I/O 配置建议

根据场景选择合适的配置：

云环境（AWS RDS/Azure/GCP）：

io_method = worker  # 最广泛兼容
io_max_concurrency = 64
effective_io_concurrency = 200

高性能 SSD 服务器：

io_method = io_uring  # 需要新内核
io_max_concurrency = 128
effective_io_concurrency = 300

开发/测试环境：

io_method = sync  # 简单可靠

7.4 监控新特性

部署后建议监控的新指标：

-- 创建监控视图
CREATE VIEW pg_monitor_aio AS
SELECT 
    state,
    operation,
    COUNT(*) as count,
    SUM(length) as total_bytes
FROM pg_aios
GROUP BY state, operation;

-- 定期检查
SELECT * FROM pg_monitor_aio;

八、总结与展望

PostgreSQL 18 是一个具有里程碑意义的版本，异步 I/O 框架为未来性能优化奠定了基础，跳跃式扫描让索引利用更加灵活，虚拟生成列简化了开发流程，UUIDv7 解决了分布式系统主键的性能痛点，OAuth 2.0 认证满足了企业安全需求。

关键性能提升总结

未来展望

PostgreSQL 的异步 I/O 框架仍在快速发展中，未来版本有望支持：

• 异步写入：WAL 和数据文件的异步写入
• 直接 I/O：绕过操作系统缓冲区
• 更多 I/O 后端：Windows IOCP、FreeBSD kqueue
• 查询级异步执行：真正的异步查询处理

PostgreSQL 18 证明了开源数据库的持续创新能力，对于追求高性能、高可靠性的应用场景，这是一个值得升级的版本。