PostgreSQL 18 深度实战：当异步 I/O 遇上 UUIDv7 —— 从全新存储引擎到生产级迁移的完全指南（2026）

前言：PostgreSQL 的「大版本之年」

2025 年 9 月 25 日，PostgreSQL 全球开发组正式发布了 PostgreSQL 18。这不是一次常规的增量更新——它是 PostgreSQL 近二十年来最激进的底层架构变革之一。

为什么说 PostgreSQL 18 是一个里程碑？

• 全新异步 I/O（AIO）子系统：彻底重写了存储层的 I/O 路径，读取性能提升高达 3 倍
• UUIDv7 原生支持：告别 UUID 无序插入导致的 B-tree 碎片化问题
• OAuth 2.0 认证：与企业的 SSO 系统无缝对接
• 虚拟生成列：查询时动态计算，不再占用存储空间
• Skip Scan 索引优化：多列索引上忽略前缀列也能走索引
• 时间区间约束（Temporal Constraints）：原生支持历史数据去重
• 新 Wire Protocol 3.2：自 PostgreSQL 7.4（2003 年）以来的首次协议升级

作为一名在生产环境中重度使用 PostgreSQL 的开发者，我在 PostgreSQL 18 发布后第一时间进行了测试和评估。本文将从架构原理、核心特性、代码实战、性能优化到生产迁移，给你一份完整的深度指南。

第一章：异步 I/O 子系统 —— PostgreSQL 存储层的「心脏移植」

1.1 问题背景：为什么 PostgreSQL 的 I/O 一直是痛点

在 PostgreSQL 18 之前，PostgreSQL 的 I/O 模型有一个根本性的限制：同步 I/O。

传统流程是这样的：

查询请求 → Buffer Pool Miss → 发起 read() 系统调用 → 等待磁盘返回 → 继续处理

每一个 I/O 请求都必须等待前一个完成。虽然操作系统有 readahead 机制，但操作系统对数据库的访问模式「一无所知」——它不知道哪些数据页即将被访问，也不知道哪些是热点数据。这导致在以下场景中性能严重受限：

1. 大表顺序扫描：百万级、亿级行的表扫描
2. Bitmap Heap Scan：位图扫描需要读取大量离散数据页
3. VACUUM 操作：清理死元组时需要遍历整个表
4. 高并发 OLTP：大量随机 I/O 争抢磁盘带宽

1.2 PostgreSQL 18 的 AIO 架构

PostgreSQL 18 引入了全新的异步 I/O 子系统，核心思想很简单：不等了，多发几个。

旧模式（同步）：
  Block 1 read() → 等待 → Block 2 read() → 等待 → Block 3 read() → 等待

新模式（异步）：
  Block 1 read() → Block 2 read() → Block 3 read() → 等待全部完成 → 处理

PostgreSQL 18 支持三种 I/O 方法，通过 io_method 参数配置：

1.3 配置 AIO

-- postgresql.conf

-- 选择 I/O 方法
io_method = 'io_uring'          -- Linux 推荐使用 io_uring
# io_method = 'worker'          -- macOS 或旧内核使用 worker

-- AIO 队列深度（控制同时发起的 I/O 请求数量）
io_depth = 256                  -- 默认值，可根据工作负载调整

-- 启用 AIO 的操作类型
enable_aio_seqscan = true       -- 顺序扫描
enable_aio_bitmapscan = true    -- 位图扫描
enable_aio_vacuum = true        -- VACUUM 操作

1.4 性能对比：AIO vs 同步 I/O

以下是一个简单的基准测试脚本，用于对比同步和异步 I/O 在大表扫描中的性能差异：

-- 创建测试表（1000 万行）
CREATE TABLE test_aio (
    id BIGSERIAL PRIMARY KEY,
    data TEXT NOT NULL,
    value NUMERIC(10,2),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    payload BYTEA
);

-- 填充测试数据
INSERT INTO test_aio (data, value, payload)
SELECT 
    md5(random()::text),
    (random() * 10000)::numeric(10,2),
    gen_random_bytes(500)
FROM generate_series(1, 10000000);

VACUUM ANALYZE test_aio;

-- 测试 1：顺序扫描（禁用索引提示）
SET enable_indexscan = off;
SET enable_bitmapscan = off;

-- 使用同步 I/O
SET io_method = 'sync';
EXPLAIN ANALYZE SELECT COUNT(*) FROM test_aio WHERE value > 5000;

-- 使用 AIO（io_uring）
SET io_method = 'io_uring';
EXPLAIN ANALYZE SELECT COUNT(*) FROM test_aio WHERE value > 5000;

在典型的 NVMe SSD 环境中，AIO 模式在大表扫描场景中通常能获得 1.5-3 倍的性能提升。提升幅度取决于以下因素：

• 存储介质：NVMe SSD 的提升最为显著（因为同步 I/O 的延迟惩罚更大）
• 数据量：表越大，AIO 的优势越明显
• 并发度：高并发场景下，AIO 的吞吐量优势更突出

1.5 生产环境 AIO 调优建议

-- 生产环境推荐配置
io_method = 'io_uring'          -- 确认内核 ≥ 5.1
io_depth = 1024                 -- 高并发场景增大队列深度
effective_io_concurrency = 256 -- 配合 AIO 调大（原默认 200）

-- 监控 AIO 统计
SELECT * FROM pg_stat_io;

-- 查看 I/O 统计（PostgreSQL 18 新增 read_bytes/write_bytes/extend_bytes）
SELECT 
    context,
    reads, read_bytes,
    writes, write_bytes,
    extends, extend_bytes
FROM pg_stat_io
ORDER BY context;

重要提示：启用 AIO 后，effective_io_concurrency 参数的作用发生了变化。在同步 I/O 模式下，这个参数控制预读页数；在 AIO 模式下，它影响并发 I/O 请求的调度策略。建议在启用 AIO 后进行基准测试，找到最优值。

第二章：UUIDv7 —— 终结 UUID 主键的「插入性能诅咒」

2.1 老问题：UUID v4 的致命缺陷

UUID v4（即 gen_random_uuid() 生成的值）是完全随机的。当你用 UUID v4 作为主键时，插入的行会被分散到 B-tree 索引的各个位置，导致：

1. 索引碎片化：每次插入都可能触发随机页写入
2. Buffer Pool 污染：热点数据页被冷数据页挤出缓存
3. WAL 放大：随机写入产生更多的 WAL 记录
4. Insert 吞吐量暴跌：相比自增整数，UUID v4 的插入性能可能下降 10-50 倍

这是 PostgreSQL 社区的「老生常谈」问题。常见的变通方案（ULID、Snowflake ID、自定义有序前缀 + UUID）都各有妥协。

2.2 UUID v7：时间有序 + 全局唯一

PostgreSQL 18 原生引入了 uuidv7() 函数，生成符合 RFC 9562 的 UUIDv7：

UUIDv7 结构（128 bits）：
|<--- Unix 毫秒时间戳（48 bits）--->|<--- 随机位（74 bits）--->|<-- 版本/变体 -->|

关键特性：

• 时间有序：前缀是毫秒级 Unix 时间戳，保证大体上的插入顺序
• 全局唯一：随机位确保即使在同一毫秒内也不会冲突
• 数据库友好：有序性使 B-tree 索引插入变为追加式写入

2.3 代码实战：从 UUID v4 迁移到 UUID v7

-- PostgreSQL 18 中 uuidv7() 直接可用
SELECT uuidv7();
-- 示例输出：0192a1b2-c3d4-7e5f-8a6b-123456789abc

-- 旧的 UUID v4 方式（仍然可用）
SELECT gen_random_uuid();
-- 示例输出：a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d

-- uuidv4() 是 gen_random_uuid() 的新别名
SELECT uuidv4();

-- 新表设计：使用 UUIDv7 作为主键
CREATE TABLE orders_v7 (
    id UUID PRIMARY KEY DEFAULT uuidv7(),
    user_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT NOT NULL,
    unit_price NUMERIC(10,2) NOT NULL,
    total_price NUMERIC(12,2) GENERATED ALWAYS AS (quantity * unit_price) STORED,
    status VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- 索引
CREATE INDEX idx_orders_v7_user_id ON orders_v7 (user_id);
CREATE INDEX idx_orders_v7_created_at ON orders_v7 (created_at);

-- 性能对比测试：UUID v4 vs UUID v7 插入性能
-- 创建两个结构相同的表

CREATE TABLE orders_v4 (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id BIGINT NOT NULL,
    amount NUMERIC(10,2)
);

CREATE TABLE orders_v7 (
    id UUID PRIMARY KEY DEFAULT uuidv7(),
    user_id BIGINT NOT NULL,
    amount NUMERIC(10,2)
);

-- 批量插入测试（各 100 万行）
INSERT INTO orders_v4 (user_id, amount)
SELECT (random() * 100000)::bigint, (random() * 1000)::numeric(10,2)
FROM generate_series(1, 1000000);

INSERT INTO orders_v7 (user_id, amount)
SELECT (random() * 100000)::bigint, (random() * 1000)::numeric(10,2)
FROM generate_series(1, 1000000);

在实际测试中，UUID v7 的插入速度通常比 UUID v4 快 3-5 倍（取决于硬件和 shared_buffers 大小）。更重要的是，UUID v7 的 B-tree 索引更加紧凑，后续的查询性能也受益于此。

2.4 UUIDv7 的高级用法

-- 使用 UUIDv7 的前缀进行时间范围查询（无需单独的时间戳索引）
-- UUIDv7 的前 48 位是毫秒时间戳，按字典序排列等同于按时间排列
SELECT * FROM orders_v7
WHERE id >= '0192a100-0000-7000-8000-000000000000'
  AND id < '0192a200-0000-7000-8000-000000000000';

-- 这等效于查询某个时间段内的记录
-- 虽然不如直接用 TIMESTAMPTZ 列精确，但在某些场景下可以利用 UUID 的有序性

-- 如果需要同时支持时间戳精确查询和 UUID 排序
-- 可以添加一个函数索引
CREATE INDEX idx_orders_v7_extract_time
ON orders_v7 (to_timestamp(('0x' || left(id::text, 12))::bigint / 1000));

第三章：虚拟生成列 —— 查询时计算，存储时省空间

3.1 生成列的前世今生

PostgreSQL 12 引入了 Stored Generated Columns（存储生成列）：列值由表达式计算，结果物理存储在磁盘上。优点是读取快，缺点是占用存储空间，且写入时需要额外的计算。

PostgreSQL 18 引入了 Virtual Generated Columns（虚拟生成列）：

3.2 代码实战：虚拟生成列

-- 默认行为改变：PG18 中 GENERATED AS 默认使用 VIRTUAL
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    price NUMERIC(10,2) NOT NULL,
    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.13,
    quantity INT NOT NULL,
    
    -- 虚拟生成列（PG18 默认 VIRTUAL）
    total_price NUMERIC(12,2) GENERATED ALWAYS AS (price * quantity) VIRTUAL,
    
    -- 含税总价（虚拟）
    total_with_tax NUMERIC(12,2) GENERATED ALWAYS AS (
        price * quantity * (1 + tax_rate)
    ) VIRTUAL,
    
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 插入数据（虚拟列不需要指定值）
INSERT INTO products (name, price, tax_rate, quantity) VALUES
    ('机械键盘', 599.00, 0.13, 100),
    ('显示器', 2999.00, 0.13, 50),
    ('鼠标垫', 49.90, 0.13, 500);

-- 查询自动计算
SELECT name, price, quantity, total_price, total_with_tax
FROM products;
/*
 name    | price  | quantity | total_price | total_with_tax
---------+--------+----------+-------------+----------------
 机械键盘  | 599.00 |      100 |    59900.00 |       67687.00
 显示器   | 2999.00|       50 |   149950.00 |      169343.50
 鼠标垫   |  49.90 |      500 |    24950.00 |       28193.50
*/

-- 为虚拟列创建索引（表达式索引）
-- 如果你经常按虚拟列筛选，索引是必要的
CREATE INDEX idx_products_total_price ON products (total_price);

-- 对虚拟生成列进行聚合查询
SELECT 
    SUM(total_price) AS grand_total,
    AVG(total_with_tax) AS avg_with_tax
FROM products;

3.3 什么时候用 Virtual，什么时候用 Stored

选择 Virtual 生成列的场景：

• 列值计算简单快速（算术运算、字符串拼接）
• 列更新频繁（避免每次更新都要重算）
• 存储空间敏感（数亿行的表，节省的存储很可观）
• 查询频率低于写入频率

选择 Stored 生成列的场景：

• 列值计算复杂（涉及子查询、聚合）
• 列被频繁查询且对延迟敏感
• 需要对列建索引（Stored 列的索引更高效）

-- 混合使用示例
CREATE TABLE invoices (
    id SERIAL PRIMARY KEY,
    customer_id INT NOT NULL,
    subtotal NUMERIC(12,2) NOT NULL,
    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.13,
    
    -- 频繁查询的用 STORED
    total_amount NUMERIC(12,2) GENERATED ALWAYS AS (
        subtotal * (1 + tax_rate)
    ) STORED,
    
    -- 偶尔查询的用 VIRTUAL
    display_text TEXT GENERATED ALWAYS AS (
        '发票 #' || id || ' 金额: ' || (subtotal * (1 + tax_rate))::text
    ) VIRTUAL
);

第四章：OAuth 2.0 认证 —— 企业 SSO 集成终于不再需要中间件

4.1 旧方案的问题

在 PostgreSQL 18 之前，如果你想让 PostgreSQL 接入企业的 SSO（如 Google Workspace、Okta、Auth0），通常需要：

1. 部署一个认证代理（如 pgbouncer + LDAP、PgBouncer + OAuth 代理）
2. 维护额外的密码同步机制
3. 使用 SCRAM-SHA-256 密码认证作为后备方案

这些方案要么复杂、要么不安全、要么两者兼有。

4.2 PostgreSQL 18 的 OAuth 认证

PostgreSQL 18 通过扩展机制原生支持 OAuth 2.0 认证：

-- pg_hba.conf 配置 OAuth 认证
# TYPE  DATABASE  USER  ADDRESS      METHOD
host    all       all   192.168.1.0/24 oauth

-- 使用 OAuth 令牌连接
-- 通过扩展处理 OAuth 令牌验证流程
-- 令牌由外部 IdP（如 Google、Okta）签发
-- PostgreSQL 验证令牌的有效性

-- 连接时携带 OAuth Bearer Token
-- psql "postgresql://host/dbname?sslmode=require&oauth_token=<token>"

OAuth 认证的工作流程：

1. 客户端应用从 IdP（如 Google）获取 OAuth Access Token
2. 客户端将 Token 传递给 PostgreSQL（通过连接参数或协议握手）
3. PostgreSQL 通过扩展验证 Token（调用 JWKS 端点验证签名）
4. 验证通过 → 建立连接
5. 验证失败 → 拒绝连接

4.3 安全相关改进

-- postgresql.conf 安全增强

-- md5 认证已被弃用（将在未来版本中移除）
# 密码认证请使用 SCRAM
password_encryption = 'scram-sha-256'

-- TLS 1.3 密码套件配置（PG18 新增）
ssl_tls13_ciphers = 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'

-- postgres_fdw 支持 SCRAM passthrough 认证
-- dblink 同样支持
-- pgcrypto 新增 SHA-2 密码哈希支持
-- FIPS 模式验证

第五章：查询优化 —— Skip Scan 和 OR 条件索引利用

5.1 Skip Scan：跳过前缀列的索引查找

这是 PostgreSQL 18 最实用的查询优化之一。考虑以下场景：

CREATE TABLE user_logs (
    tenant_id INT NOT NULL,
    user_id BIGINT NOT NULL,
    action VARCHAR(50) NOT NULL,
    detail TEXT,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- 多列索引（前缀是 tenant_id）
CREATE INDEX idx_user_logs_tenant_user 
ON user_logs (tenant_id, user_id, created_at);

-- 插入数据（3 个租户，每个租户 100 万用户）
INSERT INTO user_logs (tenant_id, user_id, action, detail)
SELECT 
    (i % 3 + 1),
    (random() * 1000000)::bigint,
    CASE (i % 5) WHEN 0 THEN 'login' WHEN 1 THEN 'view' WHEN 2 THEN 'click' 
                  WHEN 3 THEN 'purchase' ELSE 'logout' END,
    repeat('x', 100)
FROM generate_series(1, 3000000) AS i;

旧版本的问题：当你只按 user_id 查询时，多列索引无法使用（因为前缀列 tenant_id 没有在 WHERE 子句中）。

-- PostgreSQL 17 及之前：无法使用 idx_user_logs_tenant_user
EXPLAIN SELECT * FROM user_logs 
WHERE user_id = 42 
ORDER BY created_at DESC LIMIT 10;
-- 结果：Seq Scan 或使用其他索引

PostgreSQL 18 的 Skip Scan：

-- PostgreSQL 18：自动跳过 tenant_id 前缀，直接利用索引查找 user_id
EXPLAIN SELECT * FROM user_logs 
WHERE user_id = 42 
ORDER BY created_at DESC LIMIT 10;
-- 结果：Index Scan using idx_user_logs_tenant_user
-- PostgreSQL 自动枚举每个 tenant_id 值，在索引中查找 user_id = 42

Skip Scan 的工作原理：

索引结构：tenant_id | user_id | created_at

旧方式（必须指定前缀）：
  WHERE tenant_id = 1 AND user_id = 42  ✓ 走索引
  WHERE user_id = 42                     ✗ 不走索引

新方式（Skip Scan）：
  WHERE user_id = 42
  → PostgreSQL 扫描索引：
    tenant_id=1: 查找 user_id=42 → 找到则返回
    tenant_id=2: 查找 user_id=42 → 找到则返回
    tenant_id=3: 查找 user_id=42 → 找到则返回
  → 多个 index seek 合并结果

适用条件：Skip Scan 在前缀列的基数较低（distinct 值少）时效果好。如果前缀列有数万个不同值，Skip Scan 可能不如全表扫描。

5.2 OR 条件走索引

-- 旧版本：OR 条件通常不走索引
EXPLAIN SELECT * FROM user_logs
WHERE user_id = 42 OR tenant_id = 1;

-- PostgreSQL 18：可能利用索引优化 OR 条件
EXPLAIN SELECT * FROM user_logs
WHERE user_id = 42 OR tenant_id = 1;

5.3 其他查询优化

-- Hash Join 性能提升
-- Merge Join 支持增量排序（incremental sort）
-- GIN 索引支持并行构建（PG18 新增）
CREATE INDEX CONCURRENTLY idx_logs_action_gin ON user_logs USING gin (action);

-- ARM NEON/SVE 硬件加速 popcount
SELECT bit_count(B'1010101010101010'::bit(16));

第六章：时间区间约束 —— 原生支持历史数据去重

6.1 什么是时间区间约束

时间区间约束（Temporal Constraints）是 SQL 标准中的特性，用于确保同一实体的不同历史版本在时间上不重叠。PostgreSQL 18 首次原生支持这一特性。

典型应用场景：

• 价格历史：同一商品的折扣价在不同时间段不应重叠
• 合同管理：同一员工在不同部门的任期不应重叠
• 账单记录：同一订阅的不同计费周期不应有空隙

6.2 代码实战：价格管理系统

CREATE TABLE product_prices (
    product_id INT NOT NULL,
    price NUMERIC(10,2) NOT NULL,
    valid_from DATE NOT NULL,
    valid_to DATE NOT NULL,
    
    -- 时间区间主键：同一产品的价格时间段不重叠
    PRIMARY KEY (product_id, valid_from, valid_to) WITHOUT OVERLAPS,
    
    -- 价格必须在有效期内
    CHECK (valid_from <= valid_to)
);

-- 插入初始数据
INSERT INTO product_prices (product_id, price, valid_from, valid_to) VALUES
    (1, 299.00, '2025-01-01', '2025-06-30'),
    (1, 249.00, '2025-07-01', '2025-12-31'),
    (2, 159.00, '2025-01-01', '2025-12-31');

-- 尝试插入重叠的时间段 → 报错！
INSERT INTO product_prices (product_id, price, valid_from, valid_to)
VALUES (1, 199.00, '2025-06-15', '2025-08-15');
-- ERROR: conflicting key value violates exclusion constraint

-- 带 PERIOD 的外键约束
CREATE TABLE product_price_history (
    id SERIAL PRIMARY KEY,
    product_id INT NOT NULL,
    price NUMERIC(10,2) NOT NULL,
    valid_from DATE NOT NULL,
    valid_to DATE NOT NULL,
    
    -- 引用 product_prices 的时间区间
    PERIOD FOR (valid_from, valid_to),
    
    FOREIGN KEY (product_id, PERIOD valid_from TO valid_to)
    REFERENCES product_prices (product_id, PERIOD valid_from TO valid_to)
);

第七章：监控与运维增强

7.1 EXPLAIN 增强

PostgreSQL 18 的 EXPLAIN ANALYZE 自动显示 Buffer 访问信息：

EXPLAIN (ANALYZE, BUFFERS) 
SELECT * FROM user_logs WHERE user_id = 42 LIMIT 10;

/*
QUERY PLAN
--------------------------------------------------------------------
Limit (actual rows=10 loops=1)
  -> Index Scan using idx_user_logs_tenant_user on user_logs
      (actual rows=10 loops=1)
        Index Cond: (user_id = 42)
        Buffers: shared hit=42 read=8  -- 自动显示 buffer 统计
        I/O Read Time: 0.234 ms         -- I/O 读取时间
*/

-- EXPLAIN ANALYZE VERBOSE 新增 CPU/WAL/平均读取统计
EXPLAIN (ANALYZE, VERBOSE, BUFFERS)
SELECT COUNT(*) FROM test_aio WHERE value > 5000;

7.2 VACUUM 增强与 I/O 监控

-- pg_stat_all_tables 新增列：记录 VACUUM/ANALYZE 耗时
SELECT 
    relname,
    total_vacuum_time,
    total_autovacuum_time,
    total_analyze_time,
    total_autoanalyze_time
FROM pg_stat_all_tables
WHERE relname = 'user_logs';

-- 每后端 I/O 统计（PG18 新增）
SELECT * FROM pg_stat_get_backend_io(pid);

-- pg_stat_io 新增字节级统计
SELECT 
    context,
    reads, read_bytes,
    writes, write_bytes,
    extends, extend_bytes
FROM pg_stat_io;

7.3 逻辑复制增强

-- 订阅默认并行流式应用
CREATE SUBSCRIPTION my_sub
CONNECTION 'dbname=prod host=master'
PUBLICATION all_tables;

-- 新增：自动清理空闲复制槽（防止 WAL 堆积）
-- max_replication_slots_idle_timeout（postgresql.conf）

-- pg_createsubscriber 支持一键为所有数据库创建逻辑副本
-- pg_createsubscriber --all -d /data/pg18 -D /data/pg18_replica

第八章：生产级升级指南

8.1 pg_upgrade 增强

PostgreSQL 18 的 pg_upgrade 得到了显著增强：

1. 跨大版本保留统计信息：升级后不需要等待 ANALYZE 完成就能获得良好的查询性能
2. 多对象升级加速：包含大量表和序列的数据库升级更快
3. 并行检查：--jobs 参数控制并行度，加速检查阶段
4. --swap 标志：直接交换新旧数据目录，避免复制开销

# 升级步骤

# 1. 安装 PostgreSQL 18
# （略，根据操作系统选择包管理器）

# 2. 停止旧版本
pg_ctl -D /data/pg17 stop

# 3. 运行兼容性检查
/usr/lib/postgresql/18/bin/pg_upgrade \
    --old-bindir /usr/lib/postgresql/17/bin \
    --new-bindir /usr/lib/postgresql/18/bin \
    --old-datadir /data/pg17 \
    --new-datadir /data/pg18 \
    --jobs 4 \
    --check

# 4. 执行升级
/usr/lib/postgresql/18/bin/pg_upgrade \
    --old-bindir /usr/lib/postgresql/17/bin \
    --new-bindir /usr/lib/postgresql/18/bin \
    --old-datadir /data/pg17 \
    --new-datadir /data/pg18 \
    --jobs 4 \
    --swap

# 5. 启动新版本
pg_ctl -D /data/pg18 start

# 6. 运行 ANALYZE（统计信息已保留，但建议更新）
psql -c "ANALYZE VERBOSE"

8.2 注意事项

# 重要变更 1：initdb 默认启用 page checksums
# 如果从旧版本（未启用 checksums）升级，需要：
/usr/lib/postgresql/18/bin/initdb --no-data-checksums -D /data/pg18

# 重要变更 2：全文搜索和 pg_trgm 索引的 collation provider 变更
# 升级后可能需要重建这些索引：
REINDEX INDEX pg_trgm_idx;
REINDEX INDEX fts_idx;

# 重要变更 3：md5 认证已弃用
# 在 pg_hba.conf 中将 md5 替换为 scram-sha-256

8.3 回滚策略

# 如果使用 --swap 升级，回滚只需：
pg_ctl -D /data/pg18 stop
/usr/lib/postgresql/17/bin/pg_upgrade \
    --old-bindir /usr/lib/postgresql/18/bin \
    --new-bindir /usr/lib/postgresql/17/bin \
    --old-datadir /data/pg18 \
    --new-datadir /data/pg17 \
    --swap
pg_ctl -D /data/pg17 start

第九章：从 PostgreSQL 17 到 18 的迁移实战

9.1 迁移前的检查清单

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

# 2. 检查扩展兼容性
SELECT name, default_version, installed_version FROM pg_available_extensions 
WHERE installed_version IS NOT NULL;

# 3. 检查全文搜索索引
SELECT indexname, tablename FROM pg_indexes 
WHERE indexdef LIKE '%gin%' AND indexdef LIKE '%to_tsvector%';

# 4. 检查 pg_trgm 索引
SELECT indexname, tablename FROM pg_indexes 
WHERE indexdef LIKE '%pg_trgm%';

# 5. 检查 md5 认证使用情况
# 在 pg_hba.conf 中搜索 "md5"

# 6. 检查自定义 collation
SELECT collname, collprovider FROM pg_collation WHERE collowner != 0;

9.2 迁移后验证

-- 验证数据完整性
SELECT count(*) FROM important_table;

-- 验证索引完整性
REINDEX TABLE CONCURRENTLY important_table;

-- 验证查询计划
EXPLAIN ANALYZE SELECT * FROM important_table WHERE id = 1;

-- 验证 AIO 配置
SHOW io_method;
SELECT * FROM pg_stat_io;

-- 验证 UUIDv7 可用
SELECT uuidv7();

第十章：Wire Protocol 3.2 —— 22 年来的首次协议升级

PostgreSQL 18 引入了 Wire Protocol 版本 3.2，这是自 2003 年 PostgreSQL 7.4（协议 3.0）以来的首次协议升级。

这对普通用户意味着什么？短期内变化不大——libpq 仍然默认使用 3.0 协议，驱动程序和连接池器（如 PgBouncer）会逐步支持 3.2。

但长远来看，新协议为以下能力奠定了基础：

• 更高效的连接握手
• 更好的错误报告机制
• 为未来的流式结果集做准备
• 支持新的认证机制（如 OAuth）

# 查看当前连接的协议版本
psql -c "SELECT protocol_version FROM pg_stat_connections;"  -- 如果可用

性能优化总结

PostgreSQL 18 的核心优化可以总结为以下几个维度：

总结：PostgreSQL 18 值得升级吗？

我的结论是：强烈推荐。

PostgreSQL 18 不是一次「锦上添花」的更新，而是真正触及底层的架构进化：

1. AIO 子系统解决了 PostgreSQL 长期以来的 I/O 瓶颈，这是自异步提交（async commit）以来最重要的存储层改进
2. UUIDv7终结了 UUID 主键的性能争议，让分布式 ID 不再是性能的「二等公民」
3. 虚拟生成列在不牺牲功能的前提下节省存储，体现了 PostgreSQL 「实用主义」的设计哲学
4. OAuth 2.0 认证让 PostgreSQL 真正融入现代企业的身份基础设施
5. Skip Scan等查询优化是日常开发中几乎每天都会受益的改进

对于新项目，直接使用 PostgreSQL 18。对于现有项目，建议先在测试环境完整验证（特别是全文搜索索引的 collation 变更），然后按第八章的升级指南执行迁移。

PostgreSQL 的每一次大版本都在告诉业界一件事：开源数据库可以比商业数据库做得更好。 PostgreSQL 18 再次印证了这一点。

参考资源

• PostgreSQL 18 官方发布说明：https://www.postgresql.org/docs/18/release-18.html
• PostgreSQL 18 下载页面：https://www.postgresql.org/download/
• RFC 9562（UUID v7 规范）：https://www.rfc-editor.org/rfc/rfc9562
• PostgreSQL 18 OAuth 认证文档：https://www.postgresql.org/docs/18/auth-oauth.html