原文连接：
https://baijiahao.baidu.com/s?id=1589223384392431089&wfr=spider&for=pc
熟悉 MySQL 的人，都知道 InnoDB 存储引擎，如大家所知，Redo Log 是innodb 的核心事务日志之一，innodb 写入 Redo Log 后就会提交事务，而非写入到 Datafile。之后 innodb再异步地将新事务的数据异步地写入 Datafile，真正存储起来。那么 innodb 引擎有了 redo log 和 buffer pool 以后，为什么能够在提升性能的同时，还能保证不丢数据呢? Buffer Pool, Redo Log 以及 Datafile 之间的具体关系是什么呢。
另外 Innodb 还有一大堆概念，Dirty Page, LRU（Least Recently Used，最近最少使用移除，缓存淘汰算法）, LSN（日志序号 (LSN:Log sequence number) 标识特定日志文件记录在日志文件中的位置），Checkpoint 等等，这些概念在 Innodb 里是什么运作的呢？下面通过一张图来告诉大家Buffer Pool, Redo Log 以及 Datafile 的关系
大家可以把 innodb 的事务写入过程看成写作一篇文章的过程。Innodb 的写入过程其实和我们写作的过程是非常类似的。试想，领导让我们写一篇文章，发表在论坛上。然后我们想到了一个绝佳的点子，并决定要放到文章里，可是手上还有其他事情，一时半会儿写不完，又担心过后忘了，领导还等着我们答复，此时我们会怎么做呢？我们一定会先大概构思个提纲，并把提纲和一些关键细节记录到本子上，作为草稿，然后立刻告诉领导自己要写什么东西，让其确认。最后等晚上有时间了，再根据草稿去斟词酌句，编写正稿。
在这个过程中，我们用到的几个关键的东西：
我们的大脑，用来临时暂时记住我们的点子
草稿，我们需要草稿来保证不会把点子和关键的细节给忘了
正稿，这是我们最终要输出的东西
有了这几个东西，我们不仅能确保我们不会错过一篇漂亮的文章，还能快速告诉领导自己一定可以搞定这件事情。
Innodb 实际上也用到了这几个关键的东西：
Buffer Pool：就是我们的大脑
事务日志：就是我们的草稿
Datafile：就是我们的正稿
只要按照之前写文章的过程，来进行整个事务的写入操作，不仅能保证不丢失数据，而且能够快速响应。
一次写入操作是一次事务，innodb
首先把事务数据写入到 Buffer Pool 和事务日志中，也就是在大脑中记忆下来，并写下草稿。然后就可以提交事务，响应客户端了。之后innodb 在 “有时间的时候”，异步地把这次写入的数据从 Buffer Pool，或者事务日志中正式地写入到 Datafile 中，形成“正稿”。其中，innodb 为了保证事务日志这个 “草稿” 一定能无损地还原成正稿，还不能占用太多空间，事务日志需要有以下特点：事务日志中一定保存了要写入的所有数据内容事务日志只会把新事务追加在日志最后，而不会去修改之前的内容一旦事务数据被写到 datafile，事务日志中的 “草稿” 就可以删除了
通过上面 3 个特点我们可以看出，在形成 “正稿” 之前，“草稿” 是不会被删除的；同时，“草稿” 的空间是可以被循环利用的；最后，只要 “草稿” 在，我们一定能写出 “正稿”。这里还需要说明的，是Recovery 流程。也就是如果在形成 “正稿” 前，数据库 Crash了，我们需要重启整个进程，服务器，甚至只能把数据复制到另外一台服务器来进行恢复。这个时候，事务日志这个 “草稿”就发挥了它最大的作用——数据恢复。这也和我们在工作生活中常出现的问题——把事情忘了——非常类似。Buffer Pool 本质就是存储于内存中的一个数据结构，内存和人的大脑一样，是 “健忘” 的。数据库 Crash 时，Buffer Pool中的数据极大可能 “灰飞烟灭” 了。因此，事务日志就如我们贴心的 “记事本”，它把我们的记忆，保存为“草稿”，当我们忘了的时候，就可以翻开，把记忆重新回想起来。
LSN 和 Checkpoint
上面介绍了一次写入事务的情况，而数据库在使用过程中，事务都是连续不断，根据上面所述 innodb 逻辑，写 “草稿” 和写 “正稿” 速度和进度绝大部分情况下是不一样的。
再继续上面 “写作文章” 例子，如果我们的文章很长，一天写不完，而白天都有其他工作，我们只能记录草稿，只有晚上回去才能继续写正稿。那么我们就面临一个问题：我们昨天写到哪了。
最常见的办法就是，每天晚上去对照一下草稿的内容和正稿的内容，以此来判断写到哪了，但这比较花时间，因为正稿中可能包含了很多华丽的语句，我们需要思考一下才能对比上内容。
另外一个更简单的办法，就是每天晚上写完正稿后，我们在草稿上做个标记，标记下最后一条被写为正稿的内容，这样第二天晚上，我们就可以从这个标记的后面一条开始，继续写我们的正稿，而不需要去对比内容。显然第二个方法效率更高，而且没有什么额外的风险。因此innodb 就使用了这个办法。LSN 是草稿上每一条记录的编号，我们每天晚上标记下最后一条写到正稿的记录编号，这个标记的编号，就是Checkpoint。Innodb 根据这个 checkpoint，就可以很快知道上次回放到哪里，同时也可以把这个编号之前的草稿，全部删掉了。
