检查点推进通过checkpoint_lsn划定脏页可回收的安全水位线，但脏页实际回收受事务可见性、锁持有、缓冲池热度等约束；需结合业务场景调优检查点节奏与刷脏策略。
检查点推进与脏页回收边界是数据库写入性能和崩溃恢复效率的关键机制，二者紧密关联但目标不同：检查点决定“哪些修改必须落盘”，脏页回收则关注“哪些内存页可以被复用”。理解它们的协同逻辑，才能避免日志膨胀、刷脏抖动或恢复时间过长等问题。
检查点如何推进脏页回收边界
检查点本身不直接清理脏页，而是通过固化一个“最老活跃事务起点”（即 checkpoint_lsn），划定一个安全水位线：所有 LSN ≤ checkpoint_lsn 的脏页，其修改已确保持久化（或至少保证能通过 WAL 重放恢复）。此后，后台刷脏进程（如 PostgreSQL 的 bgwriter 或 MySQL InnoDB 的 page cleaner）可安全地将这些页刷回磁盘，并在刷完后将其从缓冲池中逐出或标记为可复用。
- checkpoint_lsn 越靠前，可回收的脏页越多，但频繁推进会增加 I/O 压力
- 若检查点滞后（例如因 I/O 瓶颈或配置过低），脏页持续堆积，缓冲池命中率下降，且 WAL 日志无法及时截断，可能触发日志满告警
- PostgreSQL 中可通过 red">pg_control 查看当前 checkpoint_location；MySQL InnoDB 则在 SHOW ENGINE INNODB STATUS 的 LOG 和 BUFFER POOL 部分观察 checkpoint age 与 buf_pool_wait_free 次数
脏页回收的实际约束条件
并非所有 LSN ≤ checkpoint_lsn 的脏页都能立刻被回收。回收还受以下限制：
- 页上仍有未提交事务的锁或行版本引用（如 PostgreSQL 的 tuple xmin/xmax 仍被活跃事务可见）
- 页正被其他会话读取或修改（buffer pin 或 lock held）
- 缓冲池策略限制（如 LRU 列表尾部页才优先淘汰，而某些脏页可能刚被访问过，仍在热区）
- MySQL InnoDB 还要求该页不在 flush list 头部附近（即不能太“新”），否则跳过本轮回收以避免反复刷写
调优建议：平衡推进节奏与系统负载
过度激进的检查点会导致 I/O 密集型抖动；过于保守又拖慢恢复并占用存储。关键在于匹配业务写入模式：
- 高并发短事务场景（如 OLTP）：适当缩短 checkpoint_timeout（PostgreSQL）或降低 innodb_log_checkpoint_age 目标值（MySQL），但需同步增大 shared_buffers / innodb_buffer_pool_size 缓冲能力
- 批量导入/ETL 场景：临时调大检查点间隔，配合 synchronous_commit=off（PG）或 innodb_flush_log_at_trx_commit=2（MySQL），减少同步刷日志开销
- 始终监控 checkpoint_completion_target（PG）或 innodb_max_dirty_pages_pct（MySQL）——前者控制刷脏平滑度，后者设定了脏页占比阈值，超限会强制加速刷脏
不复杂但容易忽略：检查点推进不是“清空脏页”，而是“确认底线”；脏页回收不是“立即释放”，而是“择机复用”。两者之间隔着锁、引用、缓存热度和刷盘调度——盯住 LSN 差值和脏页率，比单纯调参数更有效。
