3000帧动画图解MySQL为什么需要binlog、redo log和undo log

小鱼儿 2023-09-29 16:11 16阅读 0赞

> 全文建立在MySQL的存储引擎为InnoDB的基础上

先看一条SQL如何入库的：

![143e2fbf14db3ea55f42bbd3119fdfdb.gif][]

这是一条很简单的更新SQL，从MySQL服务端接收到SQL到落盘，先后经过了MySQL Server层和InnoDB存储引擎。

1.  Server层就像一个产品经理，分析客户的需求，并给出实现需求的方案。
2.  InnoDB就像一个基层程序员，实现产品经理给出的具体方案。

在MySQL”分析需求，实现方案“的过程中，还夹杂着内存操作和磁盘操作，以及记录各种日志。

他们到底有什么用处？他们之间到底怎么配合的？MySQL又为什么要分层呢？InnoDB里面的那一块Buffer Pool又是什么？

我们慢慢分析。

## 分层结构 ##

MySQL为什么要分为Server层和存储引擎两层呢？

这个问题官方也没有给出明确的答案，但是也不难猜，简单来说就是为了“解耦”。

Server层和存储引擎各司其职，分工明确，用户可以根据不同的需求去使用合适的存储引擎，多好的设计，对不对？

后来的发展也验证了“分层设计”的优越性：MySQL最初搭载的存储引擎是自研的只支持简单查询的MyISAM的前身ISAM，后来与Sleepycat合作研发了Berkeley DB引擎，支持了事务。江山代有才人出，技术后浪推前浪，MySQL在持续的升级着自己的存储引擎的过程中，遇到了横空出世的InnoDB，InnoDB的功能强大让MySQL倍感压力。

自己的存储引擎打不过InnoDB怎么办？

打不过就加入！

![5fe901d7fb4ce31038928d440946658b.png][]

MySQL选择了和InnoDB合作。正是因为MySQL存储引擎的插件化设计，两个公司合作的非常顺利，MySQL也在合作后不久就发布了正式支持nnoDB的4.0版本以及经典的4.1版本。

MySQL兼并天下模式也成为MySQL走向繁荣的一个重要因素。这能让MySQL长久地保持着极强竞争力。

时至今日，MySQL依然占据着极高数据库市场份额，仅次于王牌数据库Oracle。

![14e366b1824839163a2387b41cfc65ae.png][]

### Buffer Pool ###

在InnoDB里，有一块非常重要的结构——Buffer Pool。

![f4fdb3d5a39802954b149d70a72a9683.png][]

Buffer Pool是个什么东西呢？

Buffer Pool就是一块用于缓存MySQL磁盘数据的内存空间。

为什么要缓存MySQL磁盘数据呢？

我们通过一个例子说明，我们先假设没有Buffer Pool，user表里面只有一条记录，记录的age = 1，假设需要执行三条SQL：

1.  事务A：update user set age = 2
2.  事务B：update user set age = 3
3.  事务C：update user set age = 4

如果没有Buffer Pool，那执行就是这样的：

![2688d8e035a7e32c0e5d3afa13a9ab5d.png][]

从图上可以看出，每次更新都需要从磁盘拿数据（1次IO），修改完了需要刷到磁盘（1次IO），也就是每次更新都需要2次磁盘IO。三次更新需要6次磁盘IO。

而有了Buffer Pool，执行就成了这样：

![c3929b3af721d1f22f2e8dcf6a5b7fcf.png][]

从图上可以看出，只需要在第一次执行的时候将数据从磁盘拿到Buffer Pool（1次IO），第三次执行完将数据刷回磁盘（1次IO），整个过程只需要2次磁盘IO，比没有Buffer Pool节省了4次磁盘IO的时间。

当然，Buffer Pool真正的运转流程没有这么简单，具体实现细节和优化技巧还有很多，由于篇幅有限，本文不做详细描述。

我想表达的是：Buffer Pool就是将磁盘IO转换成了内存操作，节省了时间，提高了效率。

Buffer Pool是提高了效率没错，但是出现了一个问题，Buffer Pool是基于内存的，而只要一断电，内存里面的数据就会全部丢失。

如果断电的时候Buffer Pool的数据还没来得及刷到磁盘，那么这些数据不就丢失了吗？

还是上面的那个例子，如果三个事务执行完毕，在age = 4还没有刷到磁盘的时候，突然断电，数据就全部丢掉了：

![1ab75bd5d027d1f4071bf3a44c60d4cb.png][]

试想一下，如果这些丢失的数据是核心的用户交易数据，那用户能接受吗？

答案是否定的。

那InnoDB是如何做到数据不会丢失的呢？

今天的第一个日志——redo log登场了。

打不过就加入！

![79041af992764443e36e407f2e385877.png][]

MySQL兼并天下模式也成为MySQL走向繁荣的一个重要因素。这能让MySQL长久地保持着极强竞争力。

时至今日，MySQL依然占据着极高数据库市场份额，仅次于王牌数据库Oracle。

![a81552bc8b5af7c5bf7195a9bbfeeb65.png][]

### Buffer Pool ###

在InnoDB里，有一块非常重要的结构——Buffer Pool。

![81fa7984feff591531b4e89847fd462d.png][]

Buffer Pool是个什么东西呢？

Buffer Pool就是一块用于缓存MySQL磁盘数据的内存空间。

为什么要缓存MySQL磁盘数据呢？

我们通过一个例子说明，我们先假设没有Buffer Pool，user表里面只有一条记录，记录的age = 1，假设需要执行三条SQL：

1.  事务A：update user set age = 2
2.  事务B：update user set age = 3
3.  事务C：update user set age = 4

如果没有Buffer Pool，那执行就是这样的：

![a6ccf9e4f80f21718239d20f6808cfb8.png][]

而有了Buffer Pool，执行就成了这样：

![e498905e8f9dadf2c70e722d58250cfb.png][]

当然，Buffer Pool真正的运转流程没有这么简单，具体实现细节和优化技巧还有很多，由于篇幅有限，本文不做详细描述。

我想表达的是：Buffer Pool就是将磁盘IO转换成了内存操作，节省了时间，提高了效率。

Buffer Pool是提高了效率没错，但是出现了一个问题，Buffer Pool是基于内存的，而只要一断电，内存里面的数据就会全部丢失。

如果断电的时候Buffer Pool的数据还没来得及刷到磁盘，那么这些数据不就丢失了吗？

还是上面的那个例子，如果三个事务执行完毕，在age = 4还没有刷到磁盘的时候，突然断电，数据就全部丢掉了：

![298b684fe1a3f54f753070e1aa714906.png][]

试想一下，如果这些丢失的数据是核心的用户交易数据，那用户能接受吗？

答案是否定的。

那InnoDB是如何做到数据不会丢失的呢？

今天的第一个日志——redo log登场了。

### 总结 ###

1.  Buffer Pool是MySQL进程管理的一块内存空间，有减少磁盘IO次数的作用。
2.  redo log是InnoDB存储引擎的一种日志，主要作用是崩溃恢复，有三种刷盘策略，有innodb\_flush\_log\_at\_trx\_commit 参数控制，推荐设置成2。
3.  undo log是InnoDB存储引擎的一种日志，主要作用是回滚。
4.  binlog是MySQL Server层的一种日志，主要作用是归档。
5.  MySQL挂了有两种情况：操作系统挂了MySQL进程跟着挂了；操作系统没挂，但是MySQL进程挂了。

最后，再用一张图总结一下全文的知识点：

![c3433ecfd779df5871a3aab937a4c99f.png][]

### 写在最后 ###

这篇文章写在一年之前，本来觉得是一篇水文没想要发，最近无聊修改了一下发了出来，希望能够用动图的形式帮助到MySQL基础不太好的朋友，大神忽略就好。

需要强调的一点是，由于作者水平有限，本文只是浅显的从无到有地阐述了MySQL几种日志的大致作用，过程中省略了很多细节，比如Buffer Pool的实现细节，比如undo log和MVCC的关系，比如binlog buffer、change buffer的存在，比如redo log的两阶段提交。

如果您有任何问题，我们可以探讨，如果您在文中发现错误，还望您指出，万分感谢！

好了，今天的文章就到这里了。

![96a0e1bc849c4abfb706dda9bfe3b8d3.jpeg][]

[143e2fbf14db3ea55f42bbd3119fdfdb.gif]: https://img-blog.csdnimg.cn/img_convert/143e2fbf14db3ea55f42bbd3119fdfdb.gif
[5fe901d7fb4ce31038928d440946658b.png]: https://img-blog.csdnimg.cn/img_convert/5fe901d7fb4ce31038928d440946658b.png
[14e366b1824839163a2387b41cfc65ae.png]: https://img-blog.csdnimg.cn/img_convert/14e366b1824839163a2387b41cfc65ae.png
[f4fdb3d5a39802954b149d70a72a9683.png]: https://img-blog.csdnimg.cn/img_convert/f4fdb3d5a39802954b149d70a72a9683.png
[2688d8e035a7e32c0e5d3afa13a9ab5d.png]: https://img-blog.csdnimg.cn/img_convert/2688d8e035a7e32c0e5d3afa13a9ab5d.png
[c3929b3af721d1f22f2e8dcf6a5b7fcf.png]: https://img-blog.csdnimg.cn/img_convert/c3929b3af721d1f22f2e8dcf6a5b7fcf.png
[1ab75bd5d027d1f4071bf3a44c60d4cb.png]: https://img-blog.csdnimg.cn/img_convert/1ab75bd5d027d1f4071bf3a44c60d4cb.png
[79041af992764443e36e407f2e385877.png]: https://img-blog.csdnimg.cn/img_convert/79041af992764443e36e407f2e385877.png
[a81552bc8b5af7c5bf7195a9bbfeeb65.png]: https://img-blog.csdnimg.cn/img_convert/a81552bc8b5af7c5bf7195a9bbfeeb65.png
[81fa7984feff591531b4e89847fd462d.png]: https://img-blog.csdnimg.cn/img_convert/81fa7984feff591531b4e89847fd462d.png
[a6ccf9e4f80f21718239d20f6808cfb8.png]: https://img-blog.csdnimg.cn/img_convert/a6ccf9e4f80f21718239d20f6808cfb8.png
[e498905e8f9dadf2c70e722d58250cfb.png]: https://img-blog.csdnimg.cn/img_convert/e498905e8f9dadf2c70e722d58250cfb.png
[298b684fe1a3f54f753070e1aa714906.png]: https://img-blog.csdnimg.cn/img_convert/298b684fe1a3f54f753070e1aa714906.png
[c3433ecfd779df5871a3aab937a4c99f.png]: https://img-blog.csdnimg.cn/img_convert/c3433ecfd779df5871a3aab937a4c99f.png
[96a0e1bc849c4abfb706dda9bfe3b8d3.jpeg]: https://img-blog.csdnimg.cn/96a0e1bc849c4abfb706dda9bfe3b8d3.jpeg