Redo Log Checkpoint

做的事：一边写入，一边真实盯着两个LSN数字

代码-- 后台：全表更新 UPDATE orders SET amount=amount+0.0001; -- 前台：每0.4秒查一次 SHOW ENGINE INNODB STATUS; -- 关注 LOG 部分的两行： -- Log sequence number ← 当前写到哪了 -- Last checkpoint at ← checkpoint真实确认到哪了

验证：真实拍到了LSN领先、checkpoint追赶的完整过程

实测 · 本机14次轮询的真实结果（每0.4秒一次）

第1次：  LSN=7953600399   checkpoint=7953600399   （相等，起点）
第2次：  LSN=7953600429   checkpoint=7953600399   （真实领先30字节）
第3次：  LSN=7953600449   checkpoint=7953600399   （真实领先50字节，最大值）
第4次起： LSN=7953600449   checkpoint=7953600449   （真实追上了，往后一直相等）

这两个数字的差值(checkpoint age)真实反映了"redo log里已经写入、但对应的脏页还没真实刷到磁盘"的那部分内容有多少——每次事务提交，Log sequence number都会真实立刻往前推进(redo log写入是提交路径上必须完成的同步操作)；而Last checkpoint at只有等对应的脏页真实被后台线程刷完，才会跟着往前挪。本次测试里，这个差值真实最大只到50字节，几轮轮询之内就被追平——这和上一篇《Buffer Pool 脏页刷新》里观测到的"本机page cleaner追得很快"完全吻合：脏页刷得快，checkpoint自然追得也快。

结论：checkpoint age就是"离数据真正安全还差多远"的真实量尺

如果checkpoint持续追不上LSN、差值真实越拉越大，意味着redo log里堆积的"还没落盘确认"的内容越来越多——这时候如果发生真实的崩溃，重启后需要重放的redo log量就越大，崩溃恢复耗时也会真实变长(下下一篇《Crash Recovery》会真实验证重放过程)；差值持续增长还有另一个真实后果：redo log文件本身的容量是有限的(本机innodb_log_file_size决定的总容量约100MB)，如果checkpoint迟迟追不上，最老的redo log记录会因为空间不够而无法被覆盖复用，InnoDB会真实主动降速甚至暂停新事务的写入，直到checkpoint腾出空间——这也是为什么"page cleaner刷脏页的速度"和"redo log的写入速度"这两者的相对关系，真实是InnoDB持续写入压力下的核心平衡点。

分步演示：checkpoint age从出现到归零的完整轨迹

每一步都是本文上面用高频轮询跑出来的原始结果。

LSN先跑，checkpoint在后面真实追

这一步新验证的时刻

本文用到的工具

本机 MySQL 26.7.0（InnoDB），全表更新期间对SHOW ENGINE INNODB STATUS的LOG部分高频轮询
Log sequence number / Last checkpoint at：两者的差值即checkpoint age

下一篇 · MYSQL / INNODB 68

Doublewrite Buffer