我们知道，事务的四大特性之一是持久性，那么MySQL如何保证已经提交的事务对数据库中的数据的修改永久生效，包括系统崩溃或重启后能正常恢复呢？
假设没有redo log，我们在进行事务操作时，数据是先写到内存中的，即Buffer Pool，假设此时系统崩溃了，那么就会造成数据丢失，无法保证持久性。
可能有的人会想，那直接刷盘不就行了，但是想想看，MySQL为啥要先写入BufferPool而不是直接刷盘，不就是为了提高性能嘛，一次事务可能涉及到多张表，多个索引，这些需要操作的页都不一定是连续的，会产生很多的随机IO，这是我们无法接受的。
因此，mysql用的redo log来记录这些数据变化，比如记录 “第spaceID号表空间第pageNumber号页面偏移量为N处的xx改为xx” ，这样是不是直接比刷脏来的快的多了？肯定会有人问，那如果还没有写入redoLog，此时系统奔溃怎么办？这样的话，事务不算成功，数据应该恢复到事务开始前的状态，所以满足持久性。
系统崩溃，mysql重启后只要按照redo log中记录的步骤重新恢复一下数据页，那么事务对数据库做的修改就可以被恢复了，和直接刷盘相比，redo log有下列好处：
- redo日志占用的空间很小，只记录了数据变化，不是记录整条数据。
- redo日志是顺序写入磁盘的，即顺序IO。
和写数据一样，为了提高效率，MySQL也不是直接写到redo log（磁盘）里的，缓存多多益善嘛。MySQL启动时会跟系统申请一片16MB的内存即log buffer，分为n个block，和数据页一样，每个block header存储一些管理信息，tail存储一些校验字段，block body才是真正存储log的。扯远了~
那么什么时候把 log buffer刷到磁盘中呢？：
- 当buffer空间不足时，默认buffer中的redo日志量占用总buffer容量的50%时。
- 事务提交时：为了保证持久性，每次提交事务立刻把页面修改时对应的redo log刷到磁盘，否则系统崩溃后，数据无法复原。
- 脏页刷到磁盘前：脏页刷到磁盘前，会保证脏页对应的redo log也刷到磁盘。
- 后台有一个线程，大概以每秒一次的频率刷新。
- 正常关闭服务器时，会把所有buffer刷到磁盘。
- checkpoiont时。
前面几个都好理解，那么什么是checkpoint？我们知道，redo log日志是循环写入的，在服务器初始化时已经指定了总共有多少个redo log文件，每个文件最大空间是多少。那么这些文件总有写满的一天，所以MySQL用了循环写的概念，即队尾满了以后回到队头继续写。
那么问题来了，那不覆盖了队头的数据了吗？怎么保证持久性？
不用担心，当我们log写满队尾后，队头的数据大概率已经被刷到磁盘上啦。写redo log的目的就是为了数据持久性，系统奔溃后能进行数据恢复，那么如果队头的数据已经被刷新到磁盘上了，也就不要被恢复了，换而言之，这片空间可以被废物利用，覆盖了。
那么MySQL是怎么知道这片数据有没有被刷到磁盘里的呢？就是通过checkpoint_lsn啦。lsn：log sequence number，系统写入的redo日志量。
系统按照页的修改，头插法插入到flush链表中，每个控制块分别记录该页第一次修改时对应的lsn值(old_m)以及最后一次修改时对应的lsn值，也就是说，链尾的结点是最先修改的页。系统会定时把这些脏页刷到磁盘中，也就是说，该页对应的redo log可以被覆盖了！MySQL把当前flush链表中最先修改的那页的old_m值赋给checkpoint_lsn，那么lsn小于checkpoint_lsn的空间，就可以被覆盖了。这就叫一次checkpoint。
需要注意的是，不是每次flush脏页，都会进行一次checkpoint，这两个任务一般情况下是不同线程执行的，checkpoint是指，从flush链表中计算最大可以被覆盖的redo日志对应的lsn值，然后更新到redo日志中的管理信息中去。
下篇文章聊一下如何从redo log恢复数据。
