PostgreSQL 持久化卷需匹配其IO模式：WAL要求低延迟高IOPS，推荐NVMe或高性能云盘；数据卷注重持续吞吐与稳定延迟，建议XFS/ext4文件系统并合理配置条带；临时表和pg_wal应分离至独立SSD以减少争抢；云环境需实测IOPS受实例规格影响，并优化挂载参数与synchronous_commit设置以平衡性能与安全。
PostgreSQL 持久化卷的选型和配置，直接决定数据库的吞吐、延迟和稳定性。性能瓶颈往往不出现在 SQL 或配置上，而藏在底层存储——尤其是 WAL 写入、检查点刷盘、索引扫描和大表顺序读这些关键路径上。
WAL 写入对存储 IOPS 和延迟最敏感
PostgreSQL 要求 WAL（Write-Ahead Log）必须同步落盘才能确认事务提交。这意味着每次 INSERT/UPDATE/DELETE 都会触发至少一次 fsync 到持久化卷。若卷的随机写 IOPS 低或 fsync 延迟高（如某些 NFS 或低配云盘），TPS 会急剧下降，甚至出现连接堆积。
- 生产环境建议使用本地 NVMe SSD 或云厂商提供的高性能块存储（如 AWS io2/io3、阿里云 ESSD AutoPL/PL1）
- 避免将 WAL 放在机械盘、普通 NAS、或与业务数据共用同一慢速卷上
- 可通过
pg_test_fsync和pg_test_timing实测卷的 fsync 延迟和时钟精度
数据卷需兼顾吞吐、容量与一致性
主数据目录（base/）承担着检查点批量刷脏页、VACUUM 回收空间、大表顺序扫描等高吞吐任务。这里更看重持续读写带宽和稳定延迟，而非极致随机 IOPS。
- 顺序读写场景（如报表查询、逻辑复制同步）受益于高吞吐（如 >500 MB/s）
- 若使用 LVM 或 RAID，确保条带宽度匹配 PostgreSQL 的默认 8KB 页面（常见 64KB–256KB 条带较优）
- 文件系统推荐 XFS（支持 DAX、大文件高效）或 ext4（需禁用 barrier 和 journal=writeback 提升性能）
不要忽略临时卷和 pg_wal 分离的价值
临时表、排序溢出（work_mem 不足时）、哈希连接中间结果等，都依赖 temp_tablespaces。若与主数据混用同一卷，I/O 争抢会导致查询抖动。
- 为 temp_tablespaces 单独挂载一块低延迟、高 IOPS 的 SSD 卷（无需持久性可选 tmpfs，但仅限非关键只读负载）
- 强烈建议将
pg_wal目录软链到独立高速卷（ALTER SYSTEM SET wal_directory = '/fast-wal'，需重启） - 分离后，WAL 写入不再阻塞数据页刷盘，checkpoint 压力显著降低
云环境要关注“隐性限制”而非标称参数
云厂商常标注“最高 32,000 IOPS”，但实际受限于实例规格、队列深度、IO 模式（4K 随机 vs 128K 顺序）、以及是否开启加密或快照。
- 实测发现：同一 ESSD 云盘，在 c7.large 实例上可能只有标称 IOPS 的 30%，换 c7.2xlarge 后翻倍
- PostgreSQL 默认 IO 调度器是 deadline，但云盘通常绕过内核调度，建议关闭：在
/etc/fstab中加noatime,nodiratime,barrier=0（ext4）或nobarrier（XFS） - 启用
synchronous_commit = off可大幅提性能，但仅适用于可容忍极短时间数据丢失的场景（务必配合wal_writer_delay和wal_writer_flush_after平衡风险）
基本上就这些。选对卷不是堆参数，而是匹配 PostgreSQL 的 IO 模式：WAL 要低延迟，数据要稳吞吐，临时要免争抢。不复杂但容易忽略。
