在一次 PostgreSQL 性能排查中我遇到了这样一段日志checkpoints are occurring too frequently (29 seconds apart) HINT: Consider increasing the configuration parameter max_wal_size.而另一边在 PolarDB 文档/实践中却看到checkpoint 频率约 30 秒一次看起来很矛盾PostgreSQL30 秒一次是“异常需要优化”PolarDB30 秒一次是“设计行为”那么问题来了checkpoint 到底应该频繁还是稀疏研究一番后我得出了这样的结论这篇文章从原理到架构带你彻底搞清楚。一、什么是 CheckpointCheckpoint 本质是将内存中的脏页刷回磁盘并记录一个一致性恢复点在 PostgreSQL 中checkpoint 的作用包括限制 WAL 回放长度控制恢复时间保证数据持久性二、两种完全不同的 checkpoint 策略1️⃣ PostgreSQL 传统策略低频 checkpoint典型参数max_wal_size 8GB~16GB checkpoint_timeout 15min checkpoint_completion_target 0.9特点checkpoint 间隔长每次写盘量大WAL 累积多2️⃣ PolarDB / 云原生策略高频 checkpoint特点checkpoint 间隔短如 30s每次写盘量小持久化推进更频繁三、为什么 PostgreSQL 不喜欢高频 checkpoint来看一个真实现象checkpoint 每 29 秒触发一次 每次写 ~800MB ~1GB 数据问题1. 写放大严重频繁 checkpoint 会导致同一页被多次刷盘IO 压力持续升高2. WAL 增长更快checkpoint 后第一次修改页面 → full page writecheckpoint 越频繁 → WAL 越多3. 吞吐下降表现为TPS 抖动写延迟升高四、为什么 PolarDB 反而选择高频 checkpoint关键点架构不同1️⃣ PostgreSQL 架构本地存储Shared Buffers → 本地磁盘 ↑ WAL特点数据页在本地checkpoint 真正的磁盘写入IO 成本高2️⃣ PolarDB 架构计算存储分离Compute Node → Shared Storage ↓ WAL/日志驱动特点存储层分离WAL/日志更核心数据页刷写机制不同关键区别项目PostgreSQLPolarDB存储本地共享存储checkpoint成本高相对可控WAL作用辅助恢复核心同步机制优化目标吞吐优先恢复/一致性优先五、两种策略本质对比方案 A低频 checkpointPostgreSQL优点写入吞吐高IO 更集中减少写放大缺点WAL 较多崩溃恢复时间更长方案 B高频 checkpointPolarDB优点恢复更快RTO 更可控数据推进更平滑缺点写入开销更分散对传统架构不友好六、核心差异吞吐 vs 恢复可以用一句话总结PostgreSQL追求吞吐 PolarDB追求恢复能力七、如何判断你的数据库该用哪种策略适合 PostgreSQL 低频 checkpoint 的场景高并发写入OLTP批量写入本地 SSD/NVMe单机或传统主备建议max_wal_size 8GB~16GB checkpoint_timeout 15min适合高频 checkpoint 的场景云原生数据库分离式存储高可用优先对恢复时间敏感八、一个真实调优案例问题checkpoint 每 29 秒触发 Execution latency 波动明显参数max_wal_size 2GB checkpoint_timeout 5min优化max_wal_size 8GB checkpoint_timeout 15min结果checkpoint 间隔从 29s → 数分钟IO 平滑写入稳定九、一个关键认知误区很多人看到PolarDB checkpoint 30s就以为PostgreSQL 也应该这样调这是错误的。正确认知架构不同 → 最优参数完全不同十、总结PostgreSQL少 checkpoint大 checkpoint → 提升吞吐PolarDB多 checkpoint小 checkpoint → 提升恢复能力最后一条建议如果你在标准 PostgreSQL 中看到checkpoints are occurring too frequently不要犹豫先调大 max_wal_size一句话总结checkpoint 不是越频繁越好也不是越少越好而是要匹配数据库架构。