PostgreSQL 18 深度实战：当关系数据库学会「异步呼吸」——从 AIO 3×吞吐飞跃到 uuidv7 时间排序的生产级完全指南（2026）

PostgreSQL 18 是一次里程碑式的版本更新：全新的异步 I/O 子系统带来最高 3 倍的读取性能提升，虚拟生成列、uuidv7() 时间排序 UUID、OAuth 2.0 认证等开发者利器全面落地。本文从内核架构到生产实践，带你逐项拆解每一个关键特性。

一、背景：为什么 PostgreSQL 18 值得你花时间研究

如果你是一名后端工程师或 DBA， chances are 你正在使用或考虑使用 PostgreSQL。它连续多年被评为"世界上最先进的开源数据库"，在全球开发者满意度调查中常年霸榜。从 9.x 一路走到 18，每一个大版本都像是一次系统级的"固件升级"。

但 PostgreSQL 18 不同。它不仅仅是"又多了一些功能"——它是自 PostgreSQL 引入并行查询（v10）以来最大的一次架构跃迁。

核心变化一句话总结：PostgreSQL 学会了"异步呼吸"。

以前的 PostgreSQL 读取数据是同步的：发一个 I/O 请求，等操作系统返回，再发下一个。就像一个人一次只能翻一页书。PostgreSQL 18 的全新异步 I/O（AIO）子系统让数据库可以同时发起多个 I/O 请求，吞吐量在某些场景下直接翻了 3 倍。

这还不是全部。让我们一起来看看 PostgreSQL 18 的完整特性图谱。

PostgreSQL 18 关键特性一览

接下来，我们逐一深入。

二、异步 I/O 子系统：PostgreSQL 的"呼吸"革命

2.1 为什么同步 I/O 是瓶颈

PostgreSQL 之前的 I/O 模型依赖操作系统的 readahead（预读）机制。原理很简单：操作系统会猜测你接下来可能要读哪些数据块，提前帮你从磁盘读进内存。

问题在于：操作系统不了解数据库的访问模式。

举个具体例子。假设你在执行一个全表扫描（Sequential Scan），表有 1 亿行，分布在 50 万个 8KB 数据页上。操作系统的 readahead 可能会预读 128KB 或 256KB 的连续数据，但 PostgreSQL 的访问模式可能是跳跃式的——索引扫描、位图扫描、VACUUM 扫描各不相同。

这就像你让一个不了解你阅读习惯的人帮你翻书，他翻得再快也不如你自己翻得准。

更关键的是，同步 I/O 的问题是阻塞：每发一个 pread() 系统调用，进程就要等它返回才能发下一个。在高并发场景下，这意味着大量的 CPU 时间浪费在等待 I/O 上。

2.2 AIO 架构设计

PostgreSQL 18 的 AIO 子系统彻底重构了这一模型。核心设计思路：

旧模型（同步）：
进程 → pread(block1) → 等待 → 拿到数据 → 处理 → pread(block2) → 等待 → ...

新模型（异步）：
进程 → 提交 AIO 请求(block1, block2, block3, ...) → 提交其他工作 → 
     → AIO 完成回调 → 拿到所有数据 → 处理

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

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

-- 设置为 io_uring（推荐，Linux 5.1+）
SET io_method = 'io_uring';

-- 设置为 worker 线程模式（通用兼容）
SET io_method = 'worker';

-- 回退到同步模式（兼容旧行为）
SET io_method = 'sync';

io_uring 模式

io_uring 是 Linux 内核 5.1 引入的高性能异步 I/O 接口，也是 PostgreSQL 18 AIO 的首选后端。它的优势在于：

• 零拷贝提交：通过共享环形缓冲区提交 I/O 请求，不需要系统调用
• 批量提交：一次系统调用可以提交多个 I/O 请求
• 完成事件批处理：多个 I/O 完成事件可以批量处理

这是目前 Linux 上最高效的异步 I/O 机制，PostgreSQL 18 直接将其作为一等公民支持。

Worker 模式

对于不支持 io_uring 的平台（如 macOS、旧版 Linux），PostgreSQL 18 提供了基于 worker 线程的异步 I/O 实现：

• 专用 I/O worker 线程池处理实际的 read/write 操作
• 主线程通过消息队列提交 I/O 请求
• Worker 完成后通过回调通知主线程

2.3 性能实测：到底快了多少

根据 PostgreSQL 官方基准测试和社区报告：

2.4 生产级配置建议

-- postgresql.conf 推荐配置
-- 启用 AIO（Linux 环境）
io_method = 'io_uring'

-- AIO worker 数量（io_uring 模式下不需要，worker 模式下建议）
# effective_io_concurrency = 200  # 已有参数，AIO 会自动利用

-- 共享缓冲区（AIO 的效果在高缓冲命中率时更明显）
shared_buffers = '4GB'  # 物理内存的 25%，视环境调整

-- AIO 相关新增参数（根据文档调优）
# io_workers = 4          # worker 模式下的线程数
# io_depth = 64          # 每个 AIO 请求队列的深度

重要提醒：如果你从旧版本升级到 PostgreSQL 18，AIO 默认不会自动开启（向后兼容），需要手动配置 io_method。

2.5 AIO 支持的操作类型

PostgreSQL 18 的 AIO 目前支持以下操作：

1. Sequential Scans（顺序扫描）—— 最大受益者
2. Bitmap Heap Scans（位图堆扫描）
3. VACUUM 操作 —— 清理速度显著提升

后续版本预计会将 AIO 支持扩展到更多操作类型，包括索引扫描和 WAL 写入。

三、查询性能跃迁：跳跃扫描与 OR 优化

3.1 跳跃扫描（Skip Scan）

这是 PostgreSQL 18 在查询优化器方面最引人注目的改进之一。

问题场景：假设你有一个复合索引 (status, created_at, id)，你想查询所有状态的最新记录：

-- 旧版本：无法利用索引的 status 前缀列
SELECT DISTINCT ON (status) *
FROM orders
ORDER BY status, created_at DESC;

在 PostgreSQL 17 及之前，由于查询没有指定 status 的具体值，优化器无法有效使用复合索引的前缀列。它只能退化为全表扫描或使用更复杂的执行路径。

PostgreSQL 18 的解决方案：Skip Scan 让优化器可以"跳过"复合索引的前缀列，直接利用后续列。优化器会自动识别这种模式：

旧执行计划：
Seq Scan on orders  (cost=0.00..15432.00 rows=1000000)
   Filter: ...

新执行计划（Skip Scan）：
Index Scan using idx_order_status_created on orders  (cost=0.42..3200.15 rows=50)
   Skip Scan: skipping status prefix values

适用条件：

• 多列 B-tree 索引
• 查询省略了一个或多个前缀列的等值条件
• 省略的前缀列具有高基数值（唯一值数量少效果更好）

-- 实际受益场景：status 只有 5 个值，但每个 status 下有 20 万行
-- Skip Scan 只需要扫描 5 个起点，而不是 100 万行
EXPLAIN ANALYZE
SELECT * FROM orders
WHERE created_at > '2026-01-01'
ORDER BY created_at;

3.2 OR 条件的索引优化

另一个查询优化突破：PostgreSQL 18 现在可以将 WHERE 子句中的 OR 条件转换为索引扫描。

-- 旧版本：可能退化为全表扫描
SELECT * FROM products
WHERE category = 'electronics' OR price < 100;

-- PostgreSQL 18：可以分别使用 category 和 price 的索引
-- 然后合并结果（BitmapOr）

原理：优化器将 OR 条件拆分为多个独立的子查询，每个子查询使用对应的索引，最后通过 BitmapOr 合并。

这个优化在以下场景特别有用：

• 多个单列索引覆盖 OR 条件的不同部分
• 条件之间没有重叠
• 表数据量大，全表扫描代价高

3.3 并行 GIN 索引构建

GIN（Generalized Inverted Index）索引在全文搜索和 JSONB 查询中至关重要。但长期以来，GIN 索引的构建是单线程的，在大表上非常慢。

PostgreSQL 18 终于引入了 GIN 索引的并行构建：

-- 自动利用并行构建（需要 max_parallel_maintenance_workers > 0）
CREATE INDEX CONCURRENTLY idx_articles_tags ON articles USING GIN (tags);

-- 控制并行度
SET max_parallel_maintenance_workers = 4;
CREATE INDEX idx_documents_body ON documents USING GIN (to_tsvector('english', body));

至此，B-tree（v11引入）和 BRIN 之后，GIN 也加入了并行构建的行列。

3.4 连接优化

PostgreSQL 18 对连接操作也做了多项改进：

• Hash Join 加速：改进了哈希表的构建和探测算法
• Merge Join 支持增量排序：当输入数据已经部分有序时，Merge Join 可以利用增量排序减少排序开销
• 分区表连接优化：分区裁剪与连接规划的协同更好

3.5 硬件加速：ARM NEON/SVE

对于 ARM 架构（如 AWS Graviton、Apple Silicon），PostgreSQL 18 新增了 CPU 内在函数支持：

• popcount 函数使用 ARM NEON 和 SVE 指令加速
• bit_count() 函数直接受益
• 内部位图操作性能提升

-- 使用 bit_count 的场景
SELECT bit_count(B'1010101010101010'::bit(16));  -- 结果: 8

-- 在实际应用中的例子：统计用户权限位
SELECT bit_count(permissions) as active_permission_count
FROM user_roles
WHERE user_id = 12345;

四、开发者体验升级：虚拟生成列、uuidv7 与更多

4.1 虚拟生成列（Virtual Generated Columns）

生成列（Generated Columns）自 PostgreSQL 12 引入，但之前只有存储生成列（Stored Generated Columns）：列的值在写入时计算并物理存储。

PostgreSQL 18 引入了虚拟生成列（Virtual Generated Columns）：值在查询时动态计算，不占用任何存储空间。

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    price NUMERIC(10,2) NOT NULL,
    tax_rate NUMERIC(5,4) DEFAULT 0.13,
    
    -- 虚拟生成列：查询时计算，不存储
    price_with_tax NUMERIC(12,2) 
        GENERATED ALWAYS AS (price * (1 + tax_rate)) VIRTUAL,
    
    -- 存储生成列：写入时计算，占用存储（已有特性）
    price_with_tax_stored NUMERIC(12,2) 
        GENERATED ALWAYS AS (price * (1 + tax_rate)) STORED
);

-- 查询时自动计算
SELECT name, price, price_with_tax FROM products;
-- price_with_tax 的值是实时计算的

-- 虚拟列不能直接写入
INSERT INTO products (name, price) VALUES ('键盘', 299.00);
-- price_with_tax 会自动计算为 337.87

虚拟 vs 存储生成列对比：

何时选择虚拟生成列：

• 计算简单（算术运算、字符串拼接等）
• 写入频率远高于读取频率
• 不需要在该列上建索引
• 存储空间敏感

何时选择存储生成列：

• 计算复杂（涉及子查询或函数调用）
• 读取频率远高于写入频率
• 需要在该列上建索引
• 需要逻辑复制

4.2 uuidv7()：时间排序的 UUID

UUID 是分布式系统中生成唯一标识符的标准方案。但传统的 UUIDv4（随机 UUID）有一个致命缺点：无序。

-- UUIDv4：完全随机，B-tree 索引插入时频繁分裂
SELECT gen_random_uuid();
-- 示例: 550e8400-e29b-41d4-a716-446655440000

-- UUIDv7：时间有序，插入性能接近自增 ID
SELECT uuidv7();
-- 示例: 01944b3e-7f2b-7000-8000-0123456789ab
--         ^^^^^^^^^^^
--         时间戳前缀（毫秒级 Unix 时间）

UUIDv7 的优势：

1. 时间有序：前缀包含时间戳，插入时自然有序
2. B-tree 友好：减少索引页分裂，插入性能接近 BIGSERIAL
3. 全局唯一：后缀包含随机数，保证分布式唯一性
4. 缓存友好：有序插入意味着更好的缓存命中率

CREATE TABLE events (
    id UUID DEFAULT uuidv7() PRIMARY KEY,
    event_type TEXT NOT NULL,
    payload JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 批量插入测试
INSERT INTO events (event_type, payload)
SELECT 'page_view', jsonb_build_object('url', '/blog/' || i)
FROM generate_series(1, 100000) AS i;

-- 查询最近的事件（利用有序性）
SELECT * FROM events ORDER BY id DESC LIMIT 10;

PostgreSQL 18 还提供了 uuidv4() 作为 gen_random_uuid() 的别名，API 更直观。

4.3 RETURNING 子句的 OLD/NEW 支持

这是一个非常实用的开发体验改进。以前 RETURNING 只能返回 NEW 值（即操作后的值），PostgreSQL 18 支持同时返回操作前后的值：

-- UPDATE 时同时返回新旧值
UPDATE inventory
SET quantity = quantity - 1
WHERE product_id = 42 AND quantity > 0
RETURNING 
    product_id,
    quantity AS old_quantity,
    (quantity - 1) AS new_quantity;

-- DELETE 时返回被删除的行
DELETE FROM sessions
WHERE last_active < NOW() - INTERVAL '30 days'
RETURNING OLD.*;

-- INSERT 时返回新插入的行
INSERT INTO audit_log (action, details)
VALUES ('delete_expired', 'cleaned up 500 sessions')
RETURNING NEW.*;

这对审计追踪、乐观锁实现、数据迁移等场景特别有用。

4.4 时间约束（Temporal Constraints）

PostgreSQL 18 引入了 SQL:2011 标准的时间约束，支持在时间段上定义主键和唯一约束：

CREATE TABLE employee_history (
    emp_id INT NOT NULL,
    name TEXT NOT NULL,
    department TEXT,
    period TSTZRANGE NOT NULL,
    
    -- 主键约束：同一员工的时间段不能重叠
    PRIMARY KEY (emp_id, period WITHOUT OVERLAPS)
);

-- 插入数据（使用 period 成对列）
INSERT INTO employee_history (emp_id, name, department, period)
VALUES 
    (1, '张三', '工程部', tstzrange('2024-01-01', '2025-06-30')),
    (1, '张三', '产品部', tstzrange('2025-07-01', '9999-12-31'));

-- 尝试插入重叠时间段会报错
INSERT INTO employee_history (emp_id, name, department, period)
VALUES (1, '张三', '市场部', tstzrange('2025-01-01', '2025-12-31'));
-- ERROR: conflicting key value violates exclusion constraint

这在人力资源系统、合同管理、版本历史等需要追踪随时间变化的场景中非常有价值。

4.5 CREATE FOREIGN TABLE ... LIKE

PostgreSQL 18 让创建外部表更方便了——可以直接基于本地表的定义：

-- 假设本地已有一张表
CREATE TABLE local_products (
    id INT PRIMARY KEY,
    name TEXT NOT NULL,
    price NUMERIC(10,2),
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 一键创建结构相同的外部表（指向远程 PostgreSQL）
CREATE FOREIGN TABLE remote_products LIKE local_products
SERVER postgres_prod
OPTIONS (table_name 'products');

五、升级体验：不再畏惧大版本跳跃

5.1 统计信息跨版本保留

这是 DBA 们期待已久的特性。

旧版痛点：当你从 PostgreSQL 17 升级到 18 时，pg_upgrade 会迁移所有数据文件，但不迁移统计信息（pg_statistic）。升级完成后，所有表的统计信息归零，优化器只能猜测执行计划。在 ANALYZE 完成之前，查询性能可能急剧下降。对于一个有上千张表的系统，ANALYZE 可能需要运行数小时。

PostgreSQL 18 的改进：统计信息现在可以随 pg_upgrade 一起迁移。升级完成后，优化器立刻就能使用准确的统计信息选择执行计划。

5.2 pg_upgrade 增强功能

# 并行检查（利用多核加速）
pg_upgrade --jobs 8 --old-datadir /data/pg17 --new-datadir /data/pg18 \
  --old-bindir /usr/lib/postgresql/17/bin \
  --new-bindir /usr/lib/postgresql/18/bin

# --swap 模式：直接交换新旧数据目录（避免复制）
pg_upgrade --swap --link \
  --old-datadir /data/pg17 --new-datadir /data/pg18 \
  --old-bindir /usr/lib/postgresql/17/bin \
  --new-bindir /usr/lib/postgresql/18/bin

--swap 模式的意义：传统的升级流程需要复制或链接数据文件到新目录，对于 TB 级数据库来说非常耗时。--swap 直接交换新旧目录的引用，秒级完成。

5.3 完整升级检查清单

#!/bin/bash
# PostgreSQL 18 升级前检查脚本

set -euo pipefail

echo "=== 1. 检查旧版本兼容性 ==="
pg_version=$(/usr/lib/postgresql/17/bin/postgres --version)
echo "当前版本: $pg_version"

echo "=== 2. 检查已废弃特性 ==="
# md5 密码认证将在未来版本移除
echo "检查 md5 认证使用情况..."
psql -c "SELECT rolname, rolpassword FROM pg_authid 
         WHERE rolpassword LIKE 'md5%';"

echo "=== 3. 全文搜索索引检查 ==="
# PG 18 更改了全文搜索的默认排序规则提供者
# 可能需要重建 FTS 和 pg_trgm 索引
psql -c "SELECT indexname, tablename 
         FROM pg_indexes 
         WHERE indexname LIKE '%gin%' 
         AND tablename IN (
             SELECT tablename FROM pg_indexes 
             WHERE indexdef LIKE '%gin%' 
             AND indexdef LIKE '%tsvector%'
         );"

echo "=== 4. 检查页面校验和 ==="
# PG 18 默认启用页面校验和
# 如果旧集群未启用，需要使用 --no-data-checksums
pg_controldata /data/pg17 | grep checksums

echo "=== 5. 运行 pg_upgrade 检查模式 ==="
/usr/lib/postgresql/18/bin/pg_upgrade \
  --check \
  --old-datadir /data/pg17 \
  --new-datadir /data/pg18 \
  --old-bindir /usr/lib/postgresql/17/bin \
  --new-bindir /usr/lib/postgresql/18/bin \
  --jobs 8

echo "=== 检查完成 ==="

六、认证与安全：OAuth 2.0 和更多

6.1 OAuth 2.0 认证

PostgreSQL 18 引入了 OAuth 2.0 认证支持，这是数据库与企业 SSO 系统集成的重大进展。

-- pg_hba.conf 配置示例
# TYPE  DATABASE  USER  ADDRESS       METHOD
host    all       all   192.168.1.0/24 oauth

通过 PostgreSQL 扩展实现 OAuth 2.0 认证流程，支持：

• Authorization Code Grant
• Client Credentials Grant
• 与企业 IdP（如 Okta、Azure AD、Keycloak）集成

这意味着开发者可以使用公司统一的身份认证系统来管理 PostgreSQL 的访问权限，而不需要在 PostgreSQL 中单独维护用户密码。

6.2 md5 认证废弃

重要：PostgreSQL 18 正式废弃了 md5 密码认证方式，将在未来版本中移除。

-- 检查当前使用的认证方式
SELECT usename, passwd FROM pg_shadow WHERE passwd IS NOT NULL;
-- 如果密码以 'md5' 开头，需要迁移

-- 迁移到 SCRAM-SHA-256（推荐）
ALTER USER myuser WITH PASSWORD 'new_secure_password';
-- SCRAM 认证是 PostgreSQL 的默认密码认证方式

-- pg_hba.conf 中也需要更新
# 旧: host    all    all    0.0.0.0/0    md5
# 新: host    all    all    0.0.0.0/0    scram-sha-256

6.3 其他安全改进

-- TLS 1.3 专用密码套件配置
-- postgresql.conf
ssl_tls13_ciphers = 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'

-- pgcrypto 支持 SHA-2 密码哈希
SELECT crypt('my_password', gen_salt('sha256'));

-- SCRAM passthrough 认证（postgres_fdw 和 dblink）
-- 可以在连接远程 PostgreSQL 时使用 SCRAM 认证

七、文本处理增强

7.1 PG_UNICODE_FAST 排序规则

-- 创建使用 PG_UNICODE_FAST 排序规则的列
CREATE TABLE articles (
    id SERIAL PRIMARY KEY,
    title TEXT COLLATE "PG_UNICODE_FAST" NOT NULL,
    body TEXT,
    author TEXT
);

-- 大小写转换加速
SELECT UPPER(title) FROM articles WHERE id = 1;
SELECT LOWER(title) FROM articles WHERE id = 1;

-- 新增的 casefold 函数（不区分大小写的比较）
SELECT * FROM articles
WHERE casefold(title) = casefold('PostgreSQL 18 Guide');

PG_UNICODE_FAST 提供完整的 Unicode 语义（正确处理多语言大小写转换），同时通过优化实现更快的比较操作。

7.2 非确定性排序规则上的 LIKE 支持

-- 创建非确定性排序规则
CREATE COLLATION case_insensitive (
    PROVIDER = icu,
    LOCALE = 'und-u-ks-level2',
    DETERMINISTIC = FALSE
);

CREATE TABLE users (
    username TEXT COLLATE case_insensitive PRIMARY KEY,
    email TEXT
);

-- 现在可以在非确定性排序规则上使用 LIKE
SELECT * FROM users WHERE username LIKE '%admin%';
-- 之前会报错，PostgreSQL 18 支持

7.3 全文搜索默认排序规则变更

注意：PostgreSQL 18 的全文搜索现在使用集群的默认排序规则提供者（通常是 ICU），而不是总是使用 libc。这可能导致升级后需要重建全文搜索和 pg_trgm 索引：

-- 升级后可能需要执行
REINDEX INDEX idx_articles_body_tsvector;
REINDEX INDEX idx_documents_body_trgm;

八、复制与高可用改进

8.1 逻辑复制默认并行

-- 创建订阅（默认启用并行流式应用）
CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=db-primary dbname=mydb'
PUBLICATION my_publication;

-- 显式控制并行度
ALTER SUBSCRIPTION my_subscription SET (
    streaming = parallel,
    parallel_apply_workers = 4
);

逻辑复制的并行流式应用意味着多个事务可以同时被应用到订阅端，显著提升复制吞吐量。

8.2 自动清理空闲复制槽

-- 配置自动清理空闲时间过长的复制槽
-- postgresql.conf
idle_replication_slot_timeout = '7d'

-- 查看当前复制槽状态
SELECT slot_name, slot_type, active, 
       pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag_bytes
FROM pg_replication_slots;

这是一个非常实用的运维改进。空闲的复制槽会导致 WAL 文件堆积，占用大量磁盘空间，严重时甚至导致磁盘写满。PostgreSQL 18 让你可以自动清理这些僵尸槽。

8.3 写冲突报告

-- 逻辑复制写冲突现在会被记录
-- 可以在日志和 pg_stat_subscription_stats 视图中查看
SELECT subname, conflict_count, last_conflict_time
FROM pg_stat_subscription_stats;

8.4 pg_createsubscriber 增强

# 一键为所有数据库创建逻辑复制
pg_createsubscriber --all \
  --primary-dbname=mydb \
  --subscriber-dbname=mydb_replica \
  --primary-conninfo="host=primary port=5432" \
  --subscriber-conninfo="host=replica port=5432"

九、VACUUM 策略优化

9.1 主动冻结

PostgreSQL 18 优化了 VACUUM 的冻结策略，在常规 VACUUM 中主动冻结更多页面：

-- 查看表的冻结状态
SELECT relname, age(relfrozenxid) AS xid_age,
       age(relminmxid) AS mxid_age
FROM pg_class
WHERE relkind IN ('r', 't', 'm')
ORDER BY xid_age DESC
LIMIT 10;

-- 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 schemaname = 'public'
ORDER BY total_vacuum_time DESC
LIMIT 10;

这意味着：

• 减少了需要执行 VACUUM FREEZE 的频率
• 降低了冻结风暴的风险
• 在需要激进冻结时，性能更好

9.2 VACUUM 延迟追踪

-- 启用 VACUUM 延迟追踪
SET track_cost_delay_timing = on;

-- VACUUM VERBOSE 现在显示延迟信息
VACUUM VERBOSE ANALYZE my_large_table;
-- 输出中会包含：
-- delay: 1234.567 ms
-- CPU: 567.890 ms
-- WAL: 234.567 ms
-- I/O read average: 1.234 ms

十、监控与可观测性

10.1 EXPLAIN 增强

-- EXPLAIN ANALYZE 现在自动显示缓冲区访问信息
EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 12345;

-- 新增：索引查找次数
EXPLAIN ANALYZE
SELECT * FROM products WHERE category = 'electronics';

-- VERBOSE 模式新增 CPU、WAL、平均读取统计
EXPLAIN ANALYZE VERBOSE
UPDATE inventory SET quantity = quantity - 1
WHERE product_id = 42;

10.2 pg_stat_io 增强

-- 新增字节级 I/O 统计
SELECT 
    obj_name,
    read_bytes,
    write_bytes,
    extend_bytes
FROM pg_stat_io;

-- WAL I/O 活动追踪（新增）
SELECT io_path, read_ops, read_bytes
FROM pg_stat_io
WHERE io_path LIKE 'wal%';

10.3 Per-Backend 统计

-- 每个后端的 I/O 统计
SELECT 
    pid,
    usename,
    query,
    backend_io.read_bytes,
    backend_io.write_bytes
FROM pg_stat_activity
LEFT JOIN LATERAL pg_stat_get_backend_io(pid) AS backend_io ON true
WHERE state = 'active';

-- 每个后端的 WAL 统计
SELECT 
    pid,
    usename,
    query,
    backend_wal.wal_records,
    backend_wal.wal_fpi
FROM pg_stat_activity
LEFT JOIN LATERAL pg_stat_get_backend_wal(pid) AS backend_wal ON true
WHERE state = 'active';

十一、Wire Protocol v3.2：自 2003 年以来首次协议升级

PostgreSQL 18 引入了 Wire Protocol v3.2，这是自 PostgreSQL 7.4（2003年）引入 v3.0 以来的第一次协议升级。

这意味着什么？

# libpq 仍然默认使用 v3.0（向后兼容）
# 但新的客户端驱动可以选择使用 v3.2

import psycopg2  # 或其他驱动

# 连接时指定协议版本（未来版本可能支持）
# conn = psycopg2.connect(
#     host='localhost',
#     port=5432,
#     protocol_version='3.2'  # 伪代码，具体取决于驱动实现
# )

Wire Protocol v3.2 的改进包括：

• 更高效的消息编码
• 支持 AIO 的异步消息交换
• 更好的错误报告机制

对于应用开发者来说，当前不需要做任何改变——libpq 默认继续使用 v3.0，驱动和连接池会在后续版本中逐步支持 v3.2。

十二、实战演练：从零搭建 PostgreSQL 18 环境

12.1 安装与初始化

# macOS (Homebrew)
brew install postgresql@18

# Ubuntu/Debian
sudo apt install postgresql-18

# RHEL/CentOS
sudo yum install postgresql18-server
sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
sudo systemctl enable --now postgresql-18

# 从源码编译
wget https://ftp.postgresql.org/pub/source/v18.4/postgresql-18.4.tar.gz
tar xzf postgresql-18.4.tar.gz
cd postgresql-18.4
./configure --prefix=/usr/local/pgsql18 --with-icu --with-openssl
make -j8
make install

12.2 关键配置

# postgresql.conf
# 连接
listen_addresses = '*'
port = 5432
max_connections = 200

# 内存
shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 64MB
maintenance_work_mem = 512MB

# WAL
wal_level = replica
max_wal_size = 2GB
min_wal_size = 512MB

# 查询优化
random_page_cost = 1.1
effective_io_concurrency = 200

# AIO（PostgreSQL 18 新增）
io_method = 'io_uring'

# 日志
log_connections = duration
log_line_prefix = '%m [%p] %u@%d %L '
log_lock_failures = on
track_cost_delay_timing = on

# 自动清理
autovacuum = on
autovacuum_max_workers = 4
idle_replication_slot_timeout = '7d'

# 安全
password_encryption = scram-sha-256

12.3 验证 AIO 效果

-- 创建测试表
CREATE TABLE test_aio (
    id SERIAL PRIMARY KEY,
    data BYTEA DEFAULT gen_random_bytes(8000),
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 插入 1000 万行
INSERT INTO test_aio (data)
SELECT gen_random_bytes(8000)
FROM generate_series(1, 10000000);

-- 清除缓存
-- (在 Linux 上: sync && echo 3 > /proc/sys/vm/drop_caches)

-- 使用 AIO 的顺序扫描
SET io_method = 'io_uring';
EXPLAIN ANALYZE SELECT COUNT(*) FROM test_aio;

-- 使用同步模式的顺序扫描
SET io_method = 'sync';
EXPLAIN ANALYZE SELECT COUNT(*) FROM test_aio;

-- 对比两者的执行时间

12.4 uuidv7 实战

-- 创建使用 uuidv7 的表
CREATE TABLE api_logs (
    id UUID DEFAULT uuidv7() PRIMARY KEY,
    method TEXT,
    path TEXT,
    status_code INT,
    response_time_ms INT,
    request_ip INET,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 插入测试数据
INSERT INTO api_logs (method, path, status_code, response_time_ms, request_ip)
SELECT 
    (ARRAY['GET', 'POST', 'PUT', 'DELETE'])[floor(random()*4+1)::int],
    '/api/v1/' || md5(random()::text),
    (ARRAY[200, 201, 404, 500])[floor(random()*4+1)::int],
    floor(random() * 500)::int,
    ('192.168.' || floor(random()*256)::int || '.' || floor(random()*256)::int)::inet
FROM generate_series(1, 100000);

-- 利用有序性查询最新记录
SELECT * FROM api_logs ORDER BY id DESC LIMIT 20;

-- 范围查询（uuidv7 的前缀是时间戳，可以这样做）
SELECT * FROM api_logs
WHERE id >= uuidv7()  -- 简化示例
ORDER BY id ASC LIMIT 100;

十三、性能优化最佳实践

13.1 AIO 与缓冲区的协同

-- 监控缓冲区命中率
SELECT 
    name,
    blks_read,
    blks_hit,
    CASE WHEN blks_read > 0 
         THEN round(100.0 * blks_hit / (blks_read + blks_hit), 2)
         ELSE 100 
    END AS hit_rate_pct
FROM pg_statio_user_tables
ORDER BY blks_read DESC
LIMIT 20;

AIO 的最大效果在高缓冲命中率的场景中体现——因为数据已经在内存中，AIO 的异步预读可以更有效地填充缓冲区。

13.2 跳跃扫描的索引设计

-- 适合 Skip Scan 的索引设计
-- 原则：高基数值的前缀列 + 低基数值的后续列

-- 好的设计（tenant_id 值少，created_at 查询频繁）
CREATE INDEX idx_events_tenant_created 
ON events (tenant_id, created_at DESC);

-- 查询可以跳过 tenant_id 前缀
SELECT * FROM events
WHERE created_at > NOW() - INTERVAL '1 day'
ORDER BY created_at DESC;

13.3 虚拟生成列的性能考量

-- 对于频繁查询的虚拟列，考虑创建表达式索引
CREATE INDEX idx_products_price_with_tax 
ON products ((price * (1 + tax_rate)));

-- 或者使用存储生成列（如果写入不频繁）
-- 权衡：空间换时间

十四、从 PostgreSQL 17 升级的迁移指南

14.1 必须检查的变更

1. md5 认证废弃：迁移所有 md5 密码为 SCRAM-SHA-256
2. 全文搜索索引：可能需要重建（排序规则提供者变更）
3. pg_trgm 索引：可能需要重建
4. 页面校验和：如果旧集群未启用，升级时需要 --no-data-checksums

14.2 推荐升级流程

#!/bin/bash
# PostgreSQL 17 → 18 升级流程

# 1. 备份
pg_dumpall -f /backup/pre_upgrade_$(date +%Y%m%d).sql

# 2. 安装 PostgreSQL 18
sudo apt install postgresql-18

# 3. 停止旧服务
sudo systemctl stop postgresql@17-main

# 4. 初始化新集群
sudo -u postgres /usr/lib/postgresql/18/bin/initdb -D /var/lib/postgresql/18/main

# 5. 运行兼容性检查
sudo -u postgres /usr/lib/postgresql/18/bin/pg_upgrade \
  --check \
  --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 \
  --jobs $(nproc)

# 6. 执行升级（使用 --link 节省时间和空间）
sudo -u postgres /usr/lib/postgresql/18/bin/pg_upgrade \
  --link \
  --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 \
  --jobs $(nproc)

# 7. 启动新服务
sudo systemctl start postgresql@18-main

# 8. 更新 pg_hba.conf（md5 → scram-sha-256）

# 9. 重建全文搜索索引（如需要）
psql -c "REINDEX INDEX idx_fulltext_body;"

# 10. 运行 ANALYZE（如果统计信息未迁移）
psql -c "ANALYZE;"

十五、总结与展望

PostgreSQL 18 是一次非常扎实的版本更新，以下是各维度评分：

适合升级的场景：

• I/O 密集型工作负载（大表扫描、批量数据处理）
• 需要分布式唯一 ID 的微服务架构（uuidv7）
• 使用生成列的应用（虚拟生成列节省空间）
• 频繁大版本升级的运维环境（统计信息保留）
• 需要与 SSO 集成的企业环境（OAuth 2.0）

暂时观望的场景：

• 对稳定性要求极高的生产环境（建议等 18.5+ 小版本）
• 使用自定义全文搜索索引的应用（需要测试排序规则变更的影响）
• 旧版驱动和 ORM（需等待 Wire Protocol v3.2 适配）

PostgreSQL 的开发速度令人印象深刻——18 刚发布不久，19 Beta 1 就已经面世。从 AIO 到 uuidv7，从虚拟生成列到 OAuth 2.0，PostgreSQL 18 展示了一个 30 年历史的项目依然充满活力和创新能力。对于每一位后端工程师和 DBA 来说，这都是一个值得认真研究的版本。

参考资源：

• PostgreSQL 18 官方发布公告
• PostgreSQL 18 Release Notes
• PostgreSQL 18 文档
• PostgreSQL 19 Beta 1 发布（持续演进）