SQL Checkpoint 是如何工作的？

SQL Checkpoint的核心是将内存脏页批量写入磁盘并记录安全标记（如LSN/RBA），使崩溃后仅需重放该标记之后的日志即可恢复一致状态；其通过定时、日志压力、显式命令等多种机制触发，现代数据库多采用增量检查点以平滑I/O、控制MTTR。

SQL Checkpoint 的核心是把内存中已修改但尚未落盘的数据页（脏页）批量写入磁盘，同时记录一个“安全标记”，让数据库在崩溃后只需重放这个标记之后的日志，就能恢复一致状态。

脏页写入与同步落盘

数据库运行时，所有数据修改都先发生在内存缓冲区（Buffer Cache / Buffer Pool）。这些被修改过的页叫“脏页”。Checkpoint 触发后，数据库写进程（如 SQL Server 的 writer、PostgreSQL 的 checkpointer、MySQL 的 flush thread）会扫描脏页列表，将符合条件的脏页顺序写入对应的数据文件。写入不等于落盘——多数系统还会调用 fsync() 或类似机制，强制把操作系统缓存中的数据真正刷到物理磁盘，确保断电不丢数据。

检查点标记（RBA / LSN / Checkpoint Position）

Checkpoint 完成时，数据库会在控制文件、日志头或专用元数据区域记录一个关键位置标识：

• Oracle 记录 Checkpoint RBA（Redo Block Address），表示该地址之前的重做日志已无需用于实例恢复；
• SQL Server 在日志中打下 checkpoint 记录，包含当前 最小恢复日志序列号（MinLSN）；
• PostgreSQL 写入 checkpoint record 到 WAL 文件，并更新控制文件中的 checkpoint location；
• MySQL InnoDB 使用 LSN（Log Sequence Number），通过 SHOW ENGINE INNODB STATUS 可查 “Last checkpoint at” 值。

这个标记就是恢复的起点：崩溃重启后，数据库只从该标记之后的日志开始前滚（Redo）和回滚（Undo）。

触发时机与常见场景

Checkpoint 不是固定时间点执行，而是由多种条件驱动：

• 定时触发：如 PostgreSQL 默认每 5分钟（checkpoint_timeout）自动执行一次；
• 日志空间压力触发：SQL Server 日志使用超 70% 或 WAL 文件快满（PostgreSQL 的 max_wal_size 被突破）；
• 显式命令触发：执行 CHECKPOINT（SQL Server）、CHECKPOINT（PostgreSQL）、ALTER SYSTEM CHECKPOINT（Oracle）；
• 关键操作联动：数据库关闭、备份开始前、主从切换完成时，都会强制执行一次完整 checkpoint；
• 内存压力

  

  触发：缓冲区不足需淘汰脏页（如 MySQL 的 LRU flush、InnoDB 的 async flush）。

增量 vs 完全：不是每次都要全刷

现代数据库普遍采用“增量检查点”（Incremental Checkpoint）策略：

• 完全检查点（Full Checkpoint）要求一次性刷出全部脏页，开销大，仅用于关库、备份前等确定性场景；
• 增量检查点则按需推进——例如 Oracle 每 3 秒由 CKPT 进程评估条件（如 FAST_START_MTTR_TARGET、LOG_CHECKPOINT_INTERVAL），只刷一部分最老的脏块，持续平滑地维持恢复窗口可控；
• 这种机制避免了 I/O 尖峰，也使恢复时间目标（MTTR）更可预测。