Checkpoint是InnoDB记录的“一致性点”，表示该LSN之前所有修改均已持久化到磁盘，崩溃恢复时只需重放此后Redo Log即可实现最终一致；其通过Flush List按页首次修改LSN排序，结合fuzzy/sharp/LRU三类触发机制，协调脏页刷盘与日志管理。
MySQL 通过 Checkpoint 机制协调脏页刷盘与 Redo Log 管理，核心不是“实时一致”，而是“最终一致”——即崩溃后能可靠恢复到事务提交后的状态。它不靠每改一页就写一次磁盘，而是用日志+检查点双保险，在性能和可靠性之间取得平衡。
Checkpoint 怎么定义“该刷哪些页”
InnoDB 维护一个 Flush List，按页面第一次被修改时的 LSN（Log Sequence Number）升序排列。LSN 本质是 redo 日志的字节偏移量，代表“到这个位置为止，所有修改都已记录”。Checkpoint 的目标就是把 Flush List 中 LSN ≤ 当前 checkpoint LSN 的脏页，尽可能刷新到磁盘。
- 每个数据页头部存有自己的 lsn，反映它最后一次被修改产生的日志位置
- 全局有一个 checkpoint_lsn，记录最近一次 checkpoint 刷盘所覆盖的日志边界
- 只要某页的 lsn ≤ checkpoint_lsn，说明它对应的修改已由 checkpoint 保障，可以安全落盘
刷盘动作如何支撑一致性恢复
数据库宕机重启时，并不需要重放全部 redo log。InnoDB 只需从 last checkpoint at 对应的 LSN 开始回放日志即可。因为 checkpoint 之前的所有脏页都已写入磁盘，对应修改已持久化；之后的修改才需要靠 redo log 补全。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如：page A 修改后 lsn=120，page B 修改后 lsn=180；checkpoint 刷了 A，checkpoint_lsn=120
- 宕机后重启，系统读取磁盘上 A 的最新版本（lsn=120），再重放 120→180 区间日志，还原 B 的状态
- 这样既避免全量日志重做，又确保所有已提交事务的效果完整恢复
Checkpoint 触发时机直接影响一致性保障粒度
不同触发方式决定了脏页落盘的节奏和范围，共同服务于一致性目标：
- Fuzzy Checkpoint（运行中渐进刷）：由 page cleaner 线程异步执行，响应脏页比例（innodb_max_dirty_pages_pct）、redo log 使用率（log_free_ratio）等指标。避免 IO 尖峰，让一致性保障平滑落地
- Sharp Checkpoint（关闭时强制全刷）：MySQL 正常 shutdown 时触发，把所有脏页一次性刷盘。下次启动可跳过 recovery 阶段，直接加载数据，同时确保关机前所有提交事务绝对落盘
- LRU Flushing（内存压力驱动）：当 buffer pool 空闲页不足，需淘汰冷页时，若待淘汰页是脏页，必须先刷盘再释放——防止因内存换出导致已提交数据丢失
LSN 是贯穿一致性的统一标尺
LSN 不是抽象概念，而是真实存在的、可查可比的整数值。它把页面、日志、checkpoint 三个关键实体锚定在同一坐标系下：
- 执行
SHOW ENGINE INNODB STATUS\G，在 LOG 段能看到：
Log sequence number 123456789（当前已生成日志量）
Log flushed up to 123456000（已刷入 redo 文件的日志量）
Pages flushed up to 123450000（已刷入数据文件的页对应最大 lsn）
Last checkpoint at 123450000（checkpoint_lsn） - 只要 “Pages flushed up to” ≥ “Last checkpoint at”，就说明 checkpoint 承诺的那部分页确实已落盘
- 这个等式成立，是崩溃恢复能精准截断日志、快速达成一致性的物理基础
