PostgreSQL 18 深度解析：异步 I/O 革命、B-tree Skip Scan 与 UUIDv7 如何让这个 35 年老数据库变身 AI 时代的全能引擎——从架构原理到生产实战的完整指南

前言：为什么 PostgreSQL 18 是近年来最值得关注的大版本？

2025 年 9 月 25 日，PostgreSQL 全球开发组正式发布了 PostgreSQL 18。作为一个已经走过 35 年历史的开源关系型数据库，PostgreSQL 每次大版本发布都会带来令人兴奋的改进，但 PG18 的革新力度可以说是近五年来最大的一次。

为什么这么说？因为 PG18 直接动了数据库最核心的 I/O 子系统——引入了全新的异步 I/O（AIO）架构，这是一项底层基础设施级别的变革，影响范围覆盖顺序扫描、位图堆扫描、VACUUM 等几乎所有重度 I/O 操作。与此同时，B-tree Skip Scan、UUIDv7、虚拟生成列、OAuth 2.0 认证、JSON_TABLE 等一系列特性，让 PostgreSQL 从一个传统的关系型数据库，真正进化成了一个面向 AI 时代、云原生时代的数据平台。

本文将从架构原理出发，逐一深入解析 PostgreSQL 18 的每一个核心特性，配合完整的代码示例和性能基准测试，帮助你全面掌握这个"世界上最先进的开源数据库"的最新版本。

一、异步 I/O 子系统：PG18 最重磅的底层革命

1.1 为什么需要异步 I/O？

在 PostgreSQL 18 之前，数据库的 I/O 操作基本上是同步阻塞的。当一个后端进程需要读取数据页时，它会发起一个 read() 系统调用，然后阻塞等待内核完成数据传输，才能继续处理下一页。这种模式在传统 HDD 时代问题不大，但在现代 NVMe SSD 和高速网络存储（如 AWS EBS gp3、Azure Premium SSD）的场景下，同步 I/O 成为了严重的性能瓶颈。

想象一下：你开着一辆法拉利（NVMe SSD，延迟 10-100μs），却在一个红绿灯路口（系统调用开销）停下来等 2 微秒，然后再启动，再停下来……每个 I/O 请求都有固定的"启停开销"，当存储设备越快，这个开销占比就越大。

1.2 PostgreSQL 18 AIO 架构详解

PostgreSQL 18 的 AIO 子系统由核心开发者 Andres Freund（也是 Neon 的联合创始人）主导设计，其核心思想是：将多个 I/O 请求批量提交给内核，然后一次性收割结果。

核心组件

┌─────────────────────────────────────────────────┐
│                 PostgreSQL Backend               │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │ Seq Scan │  │ Bitmap   │  │ VACUUM   │  ...  │
│  │          │  │ Heap Scan│  │          │       │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘       │
│       │              │              │              │
│       └──────────┬───┴──────────────┘              │
│                  ▼                                 │
│         ┌─────────────────┐                        │
│         │   AIO Subsystem │                        │
│         │  (io_method)    │                        │
│         └────────┬────────┘                        │
│                  │                                 │
│    ┌─────────────┼─────────────┐                   │
│    ▼             ▼             ▼                   │
│ ┌──────┐   ┌──────────┐  ┌──────────┐            │
│ │ sync │   │ worker   │  │ io_uring │            │
│ │(兼容) │   │ threads  │  │ (Linux)  │            │
│ └──────┘   └──────────┘  └──────────┘            │
└─────────────────────────────────────────────────┘

三种 I/O 方法

PG18 通过 io_method 参数控制 I/O 行为，提供三种模式：

-- 查看当前 I/O 方法
SHOW io_method;

-- 设置为 io_uring（需要重启）
ALTER SYSTEM SET io_method = 'io_uring';
-- 或者使用 worker 线程（不需要特殊内核支持）
ALTER SYSTEM SET io_method = 'worker';

关键参数调优

-- 单次 I/O 合并请求的大小（8KB 页数），默认 32
SHOW io_combine_limit;       -- 32 (256KB)

-- 最大合并限制，默认 128
SHOW io_max_combine_limit;   -- 128 (1MB)

-- 异步 I/O 并发度（类似 effective_io_concurrency）
ALTER SYSTEM SET effective_io_concurrency = 200;  -- NVMe SSD 推荐值
ALTER SYSTEM SET maintenance_io_concurrency = 200;

1.3 性能实测：AIO 到底能快多少？

根据社区基准测试和实际生产数据，AIO 对不同操作的提升幅度差异较大：

位图堆扫描的提升最为显著，因为它天然就是"先收集页面号，再批量读取"的工作模式，与 AIO 的批量提交完美契合。

1.4 监控 AIO 状态

PG18 新增了 pg_aios 系统视图，可以实时查看异步 I/O 的运行状态：

-- 查看当前所有异步 I/O 操作
SELECT * FROM pg_aios;

-- 输出示例：
--  backend_type | io_object | io_context | state  | operations | file
-- --------------+-----------+------------+--------+------------+------
--  client backend | relation  | normal    | active |         12 | base/16384/24578
--  autovacuum     | relation  | vacuum    | active |          8 | base/16384/26123

二、B-tree Skip Scan：多列索引的"智能跳跃"

2.1 传统多列索引的痛点

在 PostgreSQL 17 及更早版本中，多列 B-tree 索引有一个严格的限制：查询必须包含索引的最左前缀列，否则索引无法使用。

假设你有一个索引：

CREATE INDEX idx_orders_status_date_customer 
ON orders (status, order_date, customer_id);

以下查询可以使用索引：

-- ✅ 包含最左列 status
SELECT * FROM orders WHERE status = 'pending' AND order_date = '2026-07-06';

-- ✅ 包含最左列 status
SELECT * FROM orders WHERE status = 'shipped' AND customer_id = 12345;

但这个查询无法高效使用索引：

-- ❌ 跳过了 status 列，只用 order_date 和 customer_id
SELECT * FROM orders WHERE order_date = '2026-07-06' AND customer_id = 12345;

在 PG17 中，优化器只能选择全表扫描或者对索引进行全索引扫描，效率极低。

2.2 Skip Scan 的工作原理

PostgreSQL 18 引入的 B-tree Skip Scan 打破了这个限制。其核心思路是：在索引的前缀列基数（cardinality）较低时，遍历该列的所有可能值，对每个值执行一次"跳跃式"索引查找。

索引结构 (status, order_date, customer_id):

status=cancelled → [order_date, customer_id 子树]
status=completed → [order_date, customer_id 子树]
status=pending   → [order_date, customer_id 子树] ← 跳到这里查找
status=shipped   → [order_date, customer_id 子树] ← 跳到这里查找

对于每个 status 值，在子树中用 (order_date, customer_id) 进行精确查找

如果 status 列只有 4 个不同的值，那么优化器只需要做 4 次子树查找，而不是扫描整个索引。

2.3 实战演示

-- 创建测试表
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    event_type VARCHAR(20),     -- 低基数：约 5-10 个值
    event_date DATE,            -- 中等基数
    user_id INTEGER,            -- 高基数
    payload JSONB
);

-- 插入 1000 万条测试数据
INSERT INTO events (event_type, event_date, user_id, payload)
SELECT 
    (ARRAY['click','view','purchase','signup','logout'])[floor(random()*5+1)],
    '2024-01-01'::date + (random()*900)::int,
    floor(random()*100000)::int,
    '{"source":"auto"}'::jsonb
FROM generate_series(1, 10000000);

-- 创建多列索引
CREATE INDEX idx_events_type_date_user 
ON events (event_type, event_date, user_id);

-- PG18 之前：这个查询无法使用索引（跳过了 event_type）
EXPLAIN ANALYZE
SELECT * FROM events 
WHERE event_date = '2026-07-06' AND user_id = 42;

-- PG18：优化器会选择 Skip Scan
-- 输出中会显示 "Index Skip Scan" 或类似的扫描类型

2.4 何时有效？何时无效？

Skip Scan 并不是万能的，它的效率取决于被跳过的前缀列的基数：

关键判断原则：如果被跳过列的 NDV（Number of Distinct Values）远小于表的总行数，Skip Scan 就有优势。

三、UUIDv7：告别 UUID v4 的无序噩梦

3.1 为什么 UUID v4 不适合做主键？

UUID v4 是完全随机的 128 位值，这带来了一个严重的 B-tree 索引性能问题：随机插入导致页分裂和缓存命中率下降。

UUID v4 示例：
550e8400-e29b-41d4-a716-446655440000
6ba7b810-9dad-11d1-80b4-00c04fd430c8
f47ac10b-58cc-4372-a567-0e02b2c3d479

这些值完全随机，新插入的行会随机分布到 B-tree 的各个页面，导致：

• 缓存命中率下降（热数据被随机冲散）
• 页分裂频繁（大量随机写入）
• WAL 日志量增大

3.2 UUIDv7 的设计

UUIDv7 将 Unix 时间戳（毫秒精度）编码到前 48 位，剩余位用于随机数：

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                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

关键特性：

• 时间有序：同一毫秒内生成的 UUID 天然按时间排序
• 全局唯一：随机部分保证跨节点唯一性
• B-tree 友好：顺序插入，减少页分裂

3.3 PostgreSQL 18 中使用 UUIDv7

-- 生成 UUIDv7
SELECT uuidv7();
-- 输出：0197e6a3-8b4c-7c12-9a5f-3e8d7b4c2a1e

-- 创建使用 UUIDv7 作为主键的表
CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT uuidv7(),
    customer_id INTEGER NOT NULL,
    total DECIMAL(10,2),
    created_at TIMESTAMPTZ DEFAULT now()
);

-- 批量插入测试
INSERT INTO orders (customer_id, total)
SELECT 
    floor(random()*10000)::int,
    (random()*1000)::decimal(10,2)
FROM generate_series(1, 100000);

-- 验证 UUIDv7 是时间有序的
SELECT id, created_at FROM orders ORDER BY id LIMIT 10;
-- id 的前缀会随时间递增

3.4 UUIDv7 vs UUIDv4 vs BIGSERIAL 性能对比

-- 创建三个对比表
CREATE TABLE bench_v4 (id UUID PRIMARY KEY DEFAULT gen_random_uuid(), data TEXT);
CREATE TABLE bench_v7 (id UUID PRIMARY KEY DEFAULT uuidv7(), data TEXT);
CREATE TABLE bench_seq (id BIGSERIAL PRIMARY KEY, data TEXT);

-- 各插入 100 万条，观察索引膨胀和插入速度
-- 预期结果：
-- BIGSERIAL：最快，顺序插入
-- UUIDv7：接近 BIGSERIAL 性能，顺序插入
-- UUIDv4：最慢，随机插入导致大量页分裂

3.5 迁移策略

从 UUIDv4 迁移到 UUIDv7 需要注意：

-- 方案一：新建列，双写过渡
ALTER TABLE orders ADD COLUMN new_id UUID DEFAULT uuidv7();
-- 更新现有数据（可以分批进行）
UPDATE orders SET new_id = uuidv7() WHERE new_id IS NULL;
-- 切换主键
ALTER TABLE orders DROP CONSTRAINT orders_pkey;
ALTER TABLE orders ADD PRIMARY KEY (new_id);
ALTER TABLE orders DROP COLUMN id;
ALTER TABLE orders RENAME COLUMN new_id TO id;

-- 方案二：pg_upgrade 后直接修改默认值（新数据用 v7，旧数据保留 v4）
ALTER TABLE orders ALTER COLUMN id SET DEFAULT uuidv7();

四、虚拟生成列：计算列的"零存储"方案

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

PostgreSQL 从 PG12 开始支持存储生成列（Stored Generated Columns），但这类列的值在写入时计算并物理存储，占用磁盘空间。

PostgreSQL 18 引入了虚拟生成列（Virtual Generated Columns）——值在读取时动态计算，不占用任何存储空间。这与 MySQL 的虚拟列行为一致，但 PostgreSQL 的实现更加灵活。

-- PG12-17：存储生成列（占用磁盘空间）
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    price DECIMAL(10,2),
    quantity INTEGER,
    total DECIMAL(12,2) GENERATED ALWAYS AS (price * quantity) STORED
);

-- PG18：虚拟生成列（不占存储空间）
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    price DECIMAL(10,2),
    quantity INTEGER,
    total DECIMAL(12,2) GENERATED ALWAYS AS (price * quantity) VIRTUAL
);

注意：在 PG18 中，VIRTUAL 成为生成列的默认行为，不再需要显式指定。

4.2 实战应用场景

场景一：JSON 字段的便捷访问

CREATE TABLE api_responses (
    id SERIAL PRIMARY KEY,
    raw_data JSONB,
    -- 虚拟列：从 JSON 中提取常用字段
    status_code INTEGER GENERATED ALWAYS AS ((raw_data->>'code')::int) VIRTUAL,
    message TEXT GENERATED ALWAYS AS (raw_data->>'message') VIRTUAL,
    request_id TEXT GENERATED ALWAYS AS (raw_data->'meta'->>'request_id') VIRTUAL
);

-- 查询时直接使用虚拟列，无需重复写 JSON 路径
SELECT id, status_code, message, request_id 
FROM api_responses 
WHERE status_code >= 400;

场景二：单位转换

CREATE TABLE measurements (
    id SERIAL PRIMARY KEY,
    temperature_celsius DECIMAL(5,2),
    temperature_fahrenheit DECIMAL(5,2) GENERATED ALWAYS AS 
        (temperature_celsius * 9.0/5.0 + 32) VIRTUAL,
    weight_kg DECIMAL(8,3),
    weight_lbs DECIMAL(8,3) GENERATED ALWAYS AS 
        (weight_kg * 2.20462) VIRTUAL
);

场景三：索引支持

虚拟生成列可以被索引，这在复杂表达式查询中非常有用：

-- 在虚拟列上创建索引
CREATE INDEX idx_products_total ON products (total);

-- 这个查询会使用索引
SELECT * FROM products WHERE total > 1000;

4.3 虚拟生成列的限制

• 虚拟列的表达式必须是确定性的（不能包含 random()、now() 等）
• 虚拟列不能引用其他虚拟列（只能引用物理列）
• 虚拟列不能被 UPDATE 直接修改
• 外键不能引用虚拟列
• SELECT * 会包含虚拟列，但虚拟列不参与 INSERT、UPDATE 的列列表

五、OAuth 2.0 认证：企业级安全接入

5.1 为什么需要 OAuth？

传统的 PostgreSQL 认证方式（密码、LDAP、证书）在现代云原生和微服务架构中存在一些痛点：

• 密码管理繁琐，轮换困难
• 无法与企业 SSO 系统无缝集成
• 缺乏细粒度的访问控制

PostgreSQL 18 原生支持 OAuth 2.0 认证，允许使用 OAuth 2.0 Access Token 直接连接数据库。

5.2 配置 OAuth 认证

-- pg_hba.conf 配置
-- host  all  all  0.0.0.0/0  oauth issuer=https://auth.example.com scope=openid

-- 创建 OAuth 角色
CREATE ROLE app_user WITH LOGIN;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO app_user;

5.3 客户端连接

# Python 示例：使用 OAuth token 连接
import psycopg

# 获取 OAuth token（从你的 IdP）
token = get_oauth_token_from_provider()

# 使用 token 连接 PostgreSQL
conn = psycopg.connect(
    host="db.example.com",
    dbname="mydb",
    user="app_user",
    password=token,  # OAuth access token 作为密码
    sslmode="require"
)

// Go 示例
import (
    "database/sql"
    _ "github.com/lib/pq"
)

token := getOAuthToken()
connStr := fmt.Sprintf(
    "host=db.example.com dbname=mydb user=app_user password=%s sslmode=require",
    token,
)
db, err := sql.Open("postgres", connStr)

5.4 安全最佳实践

• 始终使用 TLS：OAuth token 是明文传输的，必须加密
• 短生命周期 token：建议 Access Token 有效期不超过 1 小时
• 范围限制：使用 scope 参数限制 token 的权限范围
• 审计日志：启用 log_connections 记录所有认证事件

六、JSON_TABLE：SQL/JSON 标准的终极形态

6.1 从 JSON 中"展平"数据

JSON_TABLE 是 SQL:2016 标准的一部分，它允许你将 JSON 数组"展平"为关系型行集，就像一个函数一样在 FROM 子句中使用。

-- 原始 JSON 数据
CREATE TABLE orders_raw (
    id SERIAL PRIMARY KEY,
    order_data JSONB
);

INSERT INTO orders_raw (order_data) VALUES ('{
    "order_id": "ORD-001",
    "customer": "张三",
    "items": [
        {"name": "iPhone 16", "price": 7999, "qty": 1},
        {"name": "AirPods Pro", "price": 1899, "qty": 2},
        {"name": "MagSafe Charger", "price": 399, "qty": 1}
    ]
}');

-- 使用 JSON_TABLE 展平 items 数组
SELECT 
    r.id,
    jt.order_id,
    jt.customer,
    jt.item_name,
    jt.price,
    jt.qty,
    jt.price * jt.qty AS line_total
FROM orders_raw r,
JSON_TABLE(
    r.order_data,
    '$' COLUMNS (
        order_id TEXT PATH '$.order_id',
        customer TEXT PATH '$.customer',
        NESTED PATH '$.items[*]' COLUMNS (
            item_name TEXT PATH '$.name',
            price DECIMAL(10,2) PATH '$.price',
            qty INTEGER PATH '$.qty'
        )
    )
) AS jt;

输出：

 id | order_id | customer | item_name      |  price  | qty | line_total
----+----------+----------+----------------+---------+-----+-----------
  1 | ORD-001  | 张三     | iPhone 16      | 7999.00 |   1 |    7999.00
  1 | ORD-001  | 张三     | AirPods Pro    | 1899.00 |   2 |    3798.00
  1 | ORD-001  | 张三     | MagSafe Charger|  399.00 |   1 |     399.00

6.2 高级用法：嵌套 JSON 处理

-- 处理多层嵌套的 JSON
SELECT *
FROM JSON_TABLE(
    '[{"user":"alice","scores":[{"math":95,"english":88},{"math":92,"english":91}]}]'::jsonb,
    '$[*]' COLUMNS (
        user_name TEXT PATH '$.user',
        NESTED PATH '$.scores[*]' COLUMNS (
            math_score INT PATH '$.math',
            english_score INT PATH '$.english'
        )
    )
) AS jt;

6.3 JSON_TABLE 与传统方案的对比

-- 传统方案：使用 jsonb_array_elements + jsonb_to_record
SELECT 
    r.id,
    r.order_data->>'order_id' AS order_id,
    elem->>'name' AS item_name,
    (elem->>'price')::decimal AS price
FROM orders_raw r,
LATERAL jsonb_array_elements(r.order_data->'items') AS elem;

-- JSON_TABLE 方案：更清晰、更标准、优化器更容易优化
SELECT r.id, jt.*
FROM orders_raw r,
JSON_TABLE(r.order_data, '$' COLUMNS (
    order_id TEXT PATH '$.order_id',
    NESTED PATH '$.items[*]' COLUMNS (
        item_name TEXT PATH '$.name',
        price DECIMAL PATH '$.price'
    )
)) AS jt;

七、其他重要特性速览

7.1 pg_upgrade 保留统计信息

这是一个被严重低估的改进。在 PG17 及更早版本中，pg_upgrade 后需要运行 ANALYZE 重新收集统计信息，这个过程在大库上可能需要数小时。PG18 的 pg_upgrade 默认保留原有统计信息，升级后立即可用。

# PG18 升级后不再需要长时间的 ANALYZE
pg_upgrade --old-datadir=/var/lib/postgresql/17/data \
           --new-datadir=/var/lib/postgresql/18/data
# 统计信息自动保留！

7.2 RETURNING 子句支持 OLD/NEW

-- UPDATE 时同时返回新旧值
UPDATE users SET email = 'new@example.com' WHERE id = 1
RETURNING OLD.email AS old_email, NEW.email AS new_email;

-- DELETE 时返回被删除的行
DELETE FROM expired_sessions WHERE expire_at < now()
RETURNING OLD.* ;

-- MERGE 也支持
MERGE INTO inventory AS t
USING new_stock AS s ON t.product_id = s.product_id
WHEN MATCHED THEN UPDATE SET quantity = t.quantity + s.quantity
WHEN NOT MATCHED THEN INSERT VALUES (s.product_id, s.quantity)
RETURNING OLD.quantity AS old_qty, NEW.quantity AS new_qty;

7.3 时间范围约束（Temporal Constraints）

PG18 支持在 PRIMARY KEY、UNIQUE 和 FOREIGN KEY 上使用时间范围约束，这对于时态数据模型（temporal data model）非常重要：

-- 创建带时间范围的表
CREATE TABLE employee_roles (
    employee_id INTEGER,
    role TEXT,
    valid_during TSTZRANGE,
    PRIMARY KEY (employee_id, role, valid_during)
);

-- 插入数据
INSERT INTO employee_roles VALUES 
(1, 'developer', '[2024-01-01, 2025-06-30)'),
(1, 'tech_lead', '[2025-07-01,)');

7.4 INITDB 默认启用数据校验和

PG18 的 initdb 默认启用数据校验和（checksums），这是一个重要的可靠性改进。如果不需要校验和（如某些测试环境），可以使用 --no-data-checksums 禁用。

7.5 MD5 密码认证废弃

PG18 开始对 MD5 密码认证发出废弃警告，未来版本将完全移除。建议迁移到 SCRAM-SHA-256：

-- 检查当前使用的认证方式
SELECT rolname, rolpassword FROM pg_authid 
WHERE rolpassword LIKE 'md5%';

-- 迁移到 SCRAM-SHA-256
ALTER USER myuser WITH PASSWORD 'new_secure_password';
-- 确保 postgresql.conf 中设置：
-- password_encryption = scram-sha-256

八、与 pgvector 配合：PostgreSQL 成为 AI 数据库

8.1 pgvector 在 PG18 上的增强

虽然 pgvector 是独立扩展，但它与 PG18 的 AIO 子系统配合后，向量搜索性能有了显著提升：

-- 安装 pgvector
CREATE EXTENSION vector;

-- 创建向量表
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding VECTOR(1536),  -- OpenAI embedding 维度
    created_at TIMESTAMPTZ DEFAULT now()
);

-- 创建 HNSW 索引（PG18 AIO 加速索引构建）
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);

-- 查询相似文档
SELECT id, content, 1 - (embedding <=> query_vec) AS similarity
FROM documents, (SELECT '[0.1, 0.2, ...]'::vector AS query_vec) q
ORDER BY embedding <=> query_vec
LIMIT 10;

8.2 PG18 + pgvector vs 专用向量数据库

对于大多数 AI 应用，PostgreSQL + pgvector 已经足够，而且避免了维护多个数据系统的复杂性。

九、升级实战：从 PG17 迁移到 PG18

9.1 升级前检查清单

# 1. 检查当前版本
psql -c "SELECT version();"

# 2. 检查数据库大小
psql -c "SELECT pg_database_size(current_database());"

# 3. 检查所有扩展兼容性
psql -c "SELECT * FROM pg_available_extensions WHERE installed_version IS NOT NULL;"

# 4. 检查是否有 MD5 密码用户
psql -c "SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';"

# 5. 检查是否有非校验和集群
psql -c "SHOW data_checksums;"

9.2 使用 pg_upgrade 升级

# 安装 PG18
sudo apt install postgresql-18

# 停止旧集群
sudo systemctl stop postgresql

# 运行 pg_upgrade
sudo -u postgres /usr/lib/postgresql/18/bin/pg_upgrade \
    --old-datadir=/var/lib/postgresql/17/main \
    --new-datadir=/var/lib/postgresql/18/main \
    --old-bindir=/usr/lib/postgresql/17/bin \
    --new-bindir=/usr/lib/postgresql/18/bin \
    --link  # 使用硬链接加速

# 启动新集群
sudo systemctl start postgresql

# 更新统计信息（虽然 PG18 保留了大部分，但建议运行一次）
sudo -u postgres vacuumdb --all --analyze-in-stages

9.3 升级后优化

-- 启用 AIO
ALTER SYSTEM SET io_method = 'io_uring';  -- 或 'worker'
ALTER SYSTEM SET effective_io_concurrency = 200;

-- 调整 VACUUM 参数（利用 PG18 的 eager freeze）
ALTER SYSTEM SET vacuum_max_eager_freeze_failure_rate = 0.5;

-- 切换密码到 SCRAM-SHA-256
ALTER SYSTEM SET password_encryption = 'scram-sha-256';

-- 重载配置
SELECT pg_reload_conf();

十、性能基准测试：PG18 vs PG17

10.1 测试环境

• 硬件：Intel Xeon Platinum 8480+ (56C/112T), 512GB DDR5, NVMe SSD 3.84TB
• OS：Ubuntu 24.04 LTS, Linux 6.8
• 数据集：TPC-H 100GB
• 并发连接：64

10.2 测试结果

总结与展望

PostgreSQL 18 是一个里程碑式的版本，它的意义不仅在于引入了多少新特性，更在于它对底层基础设施的根本性重构。异步 I/O 子系统的引入，让 PostgreSQL 在高性能存储设备上终于能够充分发挥硬件潜力；B-tree Skip Scan 打破了多列索引的最左前缀限制；UUIDv7 为分布式系统提供了时间有序的主键方案；虚拟生成列让计算列不再浪费存储空间。

从更宏观的视角来看，PostgreSQL 正在从一个传统的 OLTP 数据库，进化为一个全能数据平台：通过 pgvector 支持向量搜索，通过 JSON_TABLE 支持文档数据库功能，通过 OAuth 2.0 支持现代认证体系，通过时态约束支持复杂的数据建模。

展望 PostgreSQL 19（已经在 Beta 阶段），我们将看到：

• 属性图查询（SQL/PGQ）：原生图数据库功能
• 查询提示系统：类似 Oracle Hint 的优化器干预机制
• 并行索引清理：VACUUM 多索引并行处理
• 更细粒度的日志：按进程类型的日志控制

对于还在使用 PostgreSQL 15 或更早版本的团队，现在是时候规划升级了。PostgreSQL 18 的 AIO 子系统带来的性能提升是实打实的，而 UUIDv7 和虚拟生成列等特性更是日常开发中的"甜点级"改进。

升级建议优先级：

1. 强烈推荐：AIO 子系统（性能提升 20-40%）、pg_upgrade 保留统计（减少停机时间）
2. 推荐：B-tree Skip Scan（查询优化）、UUIDv7（新项目主键）、虚拟生成列
3. 按需使用：OAuth 2.0 认证、JSON_TABLE、时间范围约束

PostgreSQL，35 岁了，依然在进化。