图片大部分来自文章底部链接，文字为自己分析总结的，如果理解错误，请麻烦指正，感谢~
Log sequence number 4310338699 ---LSN：日志序列号(1) //字节，日志生成的最新位置，最新位置出现在log buffer中 Log buffer assigned up to 4310338699 Log buffer completed up to 4310338699 Log written up to 4310338699 Log flushed up to 4310338699 ---(2) //字节，日志已经写入到log file的位置，1-2=log buffer日志量，最好是<=1M Added dirty pages up to 4310338699 Pages flushed up to 4310338699 ---(3) //字节，脏页的数量(日志字节数来衡量)，2-3=脏页的数量(日志字节为单位) Last checkpoint at 4310338699 ---(4) //字节，共享表空间上的日志记录点，最后一次检查点，及崩溃恢复时指定的起点，3-4就是崩溃恢复多跑的日志，值越大说明需要提升checkpoint的跟进速度 可以通过show engine innodb status 得出图0代码1
图0
图1 该图来自（https://www.cnblogs.com/geaozhang）
将上图至下往上分析：
（4）对应的是代码1、图1中的Last checkpoint at，是图2中的flush_lsn，图3中的checkpoint，该记录保存在共享表空间（ibdata）中
在正常关闭的时候，会主动去更新这个值。
图2 图片来源（https://blog.csdn.net/qhgxinxing）
（3）是代码1、图1中的pages flushed up to，图2中的checkpoint_lsn，图3中的lastest lsn，该记录被保存在redo log中。
图3 图片来源应该在下方的几个链接中
图1中写，3-4崩溃恢复多跑的日志量的意思是：因为在崩溃恢复的时候，回去对比checkpoint和current lsn的大小，当发现大小不一致的时候，checkpoint到current lsn的日志都会应用一遍，也就是图1中的（4）-（1）部分。而其中checkpoint-lastest lsn也就是（4）-（3）的过程中，在内存页的数已经刷新到了磁盘当中，磁盘中的数据已经是崩溃恢复前最新的数据（不包括可能丢失了的数据），所以这段过程可以算做是多跑的。
而（3）则是告诉innodb需要脏页刷盘的点（2）-（3）是脏页的数量，其实是内存页中数据和磁盘中的data不同，需要刷盘的是数据，不是日志。
（2）日志中最新的日志号，是代码1中的Log flushed up to，也是图3中的current lsn，是从redo log的ib_filelog0中，2/4block中读取最大的checkpoint值作为最新的日志号，也就是图2中的checkpoint_lsn。
（1）log buffer中的日志，是代码1中的log sequence number，在图3中没有表示。
在崩溃恢复的时候，（1）-（2）中的数据因为没有写入logfile所以会导致该部分修改丢失。
感谢以下文档提供思路和分析：
MySQL checkpoint深入分析 - GeaoZhang - 博客园
【mysql】关于checkpoint机制 - 踏雪无痕SS - 博客园
MySQL · 引擎特性 · 庖丁解InnoDB之REDO LOG
mysql源码片段 innodb启动checkpoint flush脏页 lsn几个关键点检查过程整理_qhgxinxing的博客-CSDN博客
