PostgreSQL 18 异步 I/O 变化怎样评估

PostgreSQL 18 的异步 I/O（AIO）值得评估，但不适合用“升级后所有查询都会变快”来判断。更稳妥的做法是先找出顺序扫描、位图堆扫描、VACUUM 等真正能排队多个读请求的工作负载，再固定基线、灰度参数、观察资源代价，最后决定是否保留。点查、CPU 计算或被锁等待卡住的 SQL，通常不是这项变化的主要受益者。

评估结论应该来自同一批 SQL 在相同缓存和并发条件下的前后对比；配置项只是实验变量，不能替代基准数据。

先把 AIO 的收益边界画清楚

PostgreSQL 官方发布说明把 AIO 的直接目标放在顺序扫描、位图堆扫描、VACUUM 等操作上。它允许后端排队多个读请求，减少单个请求逐页等待的机会。这里的“异步”描述的是存储 I/O 的调度方式，不等于 SQL 自动并行，也不代表每个索引点查都能得到同样收益。

建议先从慢查询或业务批处理里挑三组样本：一组数据量明显超过 shared_buffers 的顺序读，一组位图堆扫描或大表过滤，一组 VACUUM/ANALYZE。把 CPU 饱和、锁等待和网络传输占主导的样本单独标记，否则前后结果很容易被其他瓶颈盖住。

核对 io_method 和并发参数

先在测试实例记录配置，而不是直接改生产集群。PostgreSQL 18 的 io_method 有 worker、io_uring 和 sync 三种取值，默认是 worker；io_uring 还要求构建时具备 liburing。effective_io_concurrency 控制 PostgreSQL 预期可以同时执行的存储 I/O 数量，io_combine_limit 与 io_max_combine_limit 则限制合并 I/O 的大小。

# 记录当前 AIO 实验变量，避免只保存修改后的配置
SELECT name, setting, unit, context, pending_restart
FROM pg_settings
WHERE name IN (
  'io_method', 'io_workers', 'effective_io_concurrency',
  'maintenance_io_concurrency', 'io_combine_limit',
  'io_max_combine_limit', 'io_max_concurrency'
)
ORDER BY name;

# 只在测试实例或灰度实例设置；重启级参数要提前安排窗口
ALTER SYSTEM SET io_method = 'worker';
ALTER SYSTEM SET effective_io_concurrency = 16;
ALTER SYSTEM SET maintenance_io_concurrency = 16;
-- 配置修改后按集群变更流程 reload 或 restart，并记录生效时间

不要一开始就把并发值调到很高。官方文档提醒，过高的 effective_io_concurrency 可能让系统整体 I/O 延迟上升；io_method 只能在服务器启动时选择，io_workers 只在 worker 模式下有效。每次只改一个变量，才能知道收益来自哪里。

用可重复的基线做灰度对比

基线至少记录 SQL 文本、执行计划、数据规模、缓存状态、客户端并发、总耗时、CPU 和磁盘延迟。不要把第一次冷缓存执行和第二次热缓存执行直接比较。可以先用 EXPLAIN (ANALYZE, BUFFERS, SETTINGS) 保存计划与缓冲区信息，再在相同时间窗口重复多轮，比较中位数和 P95。

# 固定计划与缓冲区指标，输出用于前后对比
EXPLAIN (ANALYZE, BUFFERS, SETTINGS, TIMING OFF)
SELECT count(*)
FROM audit_event
WHERE created_at >= timestamp '2026-01-01'
  AND created_at 

灰度时重点看“收益是否稳定”和“代价是否可接受”：查询耗时下降但磁盘队列、CPU 或交互请求尾延迟明显上升，不应算成功；只有目标样本在多轮测试中改善，且其他业务指标没有恶化，才值得扩大范围。

用 pg_aios 做辅助观察，再决定是否保留

PostgreSQL 18 新增的 pg_aios 系统视图可以帮助了解异步 I/O 使用的文件句柄。它适合回答“实例是否确实存在 AIO 相关资源活动”，但不能单独证明某条 SQL 变快了。最终仍要回到计划、缓冲区、延迟和业务尾延迟。

如果测试结果不稳定，先检查存储设备、操作系统、数据集大小和缓存状态，再检查并发是否让其他请求排队。若 io_uring 构建条件不满足，不要为了追求名称上的先进而强行切换；worker 是明确可用的对照组，sync 也可以作为关闭异步执行效果的实验基线。

相关问题

PostgreSQL 18 是否必须启用 io_uring？不必须。官方提供 worker、io_uring 和 sync 三种方法，是否选择 io_uring 取决于构建条件、操作系统和实测结果。

只看 EXPLAIN 的执行时间够不够？不够。还要结合缓存状态、I/O 等待、CPU、磁盘队列和业务 P95，避免把一次偶然的缓存命中当成 AIO 收益。