io_uring是Linux 5.1内核引入的异步I/O框架，通过用户态与内核态共享的环形队列提交请求和收割结果，避免了传统AIO每次操作都要陷入内核的额外开销。PostgreSQL社区经过多年讨论，终于在17版本落地了异步I/O基础设施，其中io_uring是最受关注的后端实现。对于读密集型的分析型负载、大表扫描以及大量并发回放的备库来说，这套机制带来的收益相当可观。本文将从原理、配置、压测三个层面展开，帮你把这套新特性真正用起来。
一、io_uring的核心原理与PostgreSQL的接入方式
传统的libaio虽然也提供异步I/O能力，但接口设计存在明显短板：每次提交I/O请求都需要至少一次系统调用，完成结果还要通过io_getevents再陷入内核获取，在高并发场景下系统调用本身就成了瓶颈。io_uring的思路完全不同，它在用户态和内核态之间建立两块共享内存环形队列，一块叫SQ（提交队列），一块叫CQ（完成队列）。应用把请求写进SQ环，内核消费后把结果写进CQ环，整个过程可以做到零系统调用，或者在开启SQPOLL模式时由专门的内核线程代为轮询。
PostgreSQL的异步I/O工作方式可以概括为“异步读、同步写”。当上层代码发起一次读缓冲请求时，backend进程会向io_uring实例提交一个读操作，然后继续处理其他工作（比如预取后续页面），等到真正需要这份数据时再收割完成事件。这种流水线式的预取对顺序扫描和索引扫描都有效。写入路径目前仍然以同步为主，这是为了避免复杂的 WAL 一致性问题，社区也在持续推进 buffer 写回的异步化。
在PostgreSQL 17中，相关行为由io_method和io_uring`相关参数控制。编译时需要确认安装了liburing开发包，否则io_method = io_uring会直接报错。可以通过下面的SQL确认当前实例支持的I/O方式：
-- 查看当前生效的异步I/O方法 SHOW io_method; -- 查看每个backend允许的并发I/O请求数 SHOW io_max_combine_limit; -- 查看预取相关配置 SHOW effective_io_concurrency;
二、关键参数配置与调优建议
启用io_uring的第一步是在postgresql.conf中设置io_method = 'io_uring'。默认值是worker，即使用进程池模拟异步，性能提升有限但兼容性最好。三个可选值分别是sync（纯同步）、worker、io_uring和io_uring`两种ring模式的区分主要在内核版本支持上。修改该参数需要重启实例。
effective_io_concurrency决定了每个backend一次预取多少个页面，机械盘建议设为1到2，NVMe SSD可以给到128甚至256。配套的maintenance_io_concurrency影响VACUUM和CREATE INDEX的预取深度。在17版本中还引入了io_combine_limit，它允许把多个相邻块的请求合并成一次大的I/O操作，直接决定了单次读操作的最大尺寸（默认128KB，最大可到1MB）。对于大表扫描场景，把这个值调大往往比单纯提高并发数更有效。
还有一个实验性参数debug_io_direct值得单独说明。它可以让数据文件读写绕过操作系统页面缓存，直接走Direct I/O，可选值包括data、wal、pgdata等组合。绕过双缓冲能减少内存浪费和一次拷贝，但风险是失去了OS缓存的兜底，一旦shared_buffers配得太小，性能反而崩塌。社区目前把它标记为开发者选项，建议先在测试环境验证。一个相对稳妥的起步配置如下：
# postgresql.conf 异步I/O相关配置 io_method = 'io_uring' effective_io_concurrency = 256 # NVMe SSD场景 maintenance_io_concurrency = 128 io_combine_limit = 512kB # 增大合并读取尺寸 # 谨慎开启，建议先测试 # debug_io_direct = data, wal
三、压测验证与常见坑
配置是否有效，最终要用数据说话。可以用pg_prewarm配合EXPLAIN (ANALYZE, BUFFERS)来观察大表扫描的行为。下面这个例子对比了worker模式和io_uring模式下的顺序扫描耗时：
-- 预热后清缓存场景下测试（重启实例模拟冷缓存） EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM big_table WHERE col BETWEEN 1 AND 1000000; -- worker模式: Planning Time: 0.1 ms -- Execution Time: 8452.3 ms Buffers: shared read=125000 -- io_uring模式: Planning Time: 0.1 ms -- Execution Time: 4127.6 ms Buffers: shared read=125000
在这类全表扫描场景下，io_uring配合较高的effective_io_concurrency通常能带来接近一倍的吞吐提升，因为等待I/O的时间被大量预取重叠掉了。但要注意它不是万能药：如果数据基本都命中shared_buffers，异步I/O几乎没有收益；OLTP型的小随机读收益也远不如大扫描明显。
实际部署中有几个坑需要留意。第一，内核版本要达标，建议Linux 5.10以上，老旧内核的io_uring实现存在已知的bug甚至安全漏洞，部分发行版默认通过kernel.io_uring_disabled禁用了它，需要检查sysctl设置。第二，容器环境要确认seccomp profile没有拦截io_uring_setup等系统调用，Docker默认配置在某些版本会直接拒绝。第三，如果开启Direct I/O，务必重新评估shared_buffers的大小，一般建议提升到内存的40%以上。第四，云厂商的托管数据库（如RDS）通常不暴露io_method配置，自建实例才有操作空间。
总结来说，io_uring给PostgreSQL带来的I/O路径现代化是一次质变，尤其适合读密集的分析负载和大批量维护操作。建议的落地路径是：先在测试环境用真实数据量验证收益，确认内核与容器环境支持后再上生产，并持续观察pg_stat_io视图中的读写统计，用数据驱动后续的参数微调。
PostgreSQLio_uringI/O性能优化修改时间：2026-09-08 12:26:57