checkpoin是重做日志对数据页刷新到磁盘的操作做的检查点，通过LSN号保存记录，作用是当发生宕机等crash情况时，再次启动时会查询checkpoint点，在该检查点之后发生的事物修改恢复到磁盘。

mysql> show engine innodb status\G;

---

LOG

---

Log sequence number 10623965866

Log flushed up to   10623965866

Pages flushed up to 10623965866

Last checkpoint at  10623965857

0 pending log flushes, 0 pending chkp writes

13 log i/o's done, 0.81 log i/o's/second


Last checkpoint at就是系统最后一次刷新buffer pool中页数据到磁盘的checkpoint，checkpoint是和redo log进行关联操作的，也就记录在redo log中，checkpoint记录在redo log第一个文件的头部，存储两个值循环更替修改。


LSN（log sequence number）日志序列号，5.6.3之后占用8字节，LSN主要用于发生crash时对数据进行recovery，LSN是一个一直递增的整型数字，表示事务写入到日志的字节总量。


LSN不仅只存在于重做日志中，在每个数据页头部也会有对应的LSN号，该LSN记录当前页最后一次修改的LSN号，用于在recovery时对比重做日志LSN号决定是否对该页进行恢复数据。前面说的checkpoint也是有LSN号记录的，LSN号串联起一个事务开始到恢复的过程。


---

LOG

---

Log sequence number 10623965866

Log flushed up to   10623965866

Pages flushed up to 10623965866

Last checkpoint at  10623965857

0 pending log flushes, 0 pending chkp writes

13 log i/o's done, 0.81 log i/o's/second


再用上面的结果看下,log sequence number就是当前产生最新的日志序列号

    log flushed up to:已经刷新到redo log磁盘文件的LSN号

    pages flushed up to:该项是5.6新加入的，这个官网也未做介绍，而又先于checkpoint，个人理解为已经在buffer poll中写入到数据脏页上的LSN号


在生产环境中往往last checkpoint 会落后log sequence number许多，checkpoint记录数据页刷新情况，而数据页刷新是有MySQL内部机制决定，所以会存在差值，而为了保证数据库发生crash再启动数据不丢失，我们需要把redo log刷新配置项innodb_flush_sync配置为1，让redo log在事务结束时就刷新到磁盘，以用redo log来做数据恢复。所以log flushed up to的LSN号都会与log sequence number一致。