【大白话系列】MySQL 学习总结 之 InnoDB 存储引擎的架构设计

1、存储引擎

上节咱们最后说到，SQL 的执行计划是执行器组件调用存储引擎的接口来完成的。 那咱们能够理解为：MySQL 这个数据库管理系统是依靠存储引擎与存放数据的磁盘文件进行交互的。

那么 MySQL 有哪些存储引擎呢？ 主要有 MyISAM、InnoDB、Memory等等。而如今互联网中，基本都是使用 InnoDB 存储引擎，因此接下来我将简单总结本身关于 InnoDB 存储引擎的学习，比较简单的介绍 InnoDB 存储引擎里面的组件。

2、缓冲池

咱们如今都知道了，数据库的数据是存放在磁盘文件中的。 那么，咱们每次对表的增删改查都是直接在磁盘文件里面操做吗？

答案：不是的！ 由于磁盘文件的随机读写的性能是很是差的，若是全部操做都在磁盘中进行，那么就不会有高性能 MySQL 的说法了，MySQL 也不能支持高并发，也不会在互联网中如此的流行。

这时候要引入 InnoDB 存储引擎最重要的一个组件，就是缓冲池（Buffer Pool），它是一个很是重要的内存结构。它是内存里面的，凭借着内存很是高性能的读写，使得 MySQL 可以支持高并发。

缓冲池（Buffer Pool） 的使用原理：

咱们先复习一下 MySQL 接收请求的过程。 ①、MySQL 的工做线程专门监听数据库链接池的链接，有链接就获取链接中的 SQL 语句。 ②、而后将 SQL 语句交给 SQL 接口 去处理，SQL 接口里会进行下面的一系列流程。 ③、查询解析器 将 SQL 语句解析成 MySQL 能理解的东西。 ④、接着 查询优化器 去为 SQL 语句制定一套最优的执行计划。 ⑤、执行器 会根据执行计划去调用存储引擎的接口。

上面是上篇文章总结到的东西，那么存储引擎的接口是怎么进行增删改查的呢？以更新操做为例，其余的同理。 首先，存储引擎会先判断更新 SQL 对应的数据行是否在 缓冲池（Buffer Pool） 里面。若是在的话就直接在 缓冲池（Buffer Pool） 里更新数据而后返回；若是不在，则从磁盘文件里读取数据到 缓冲池（Buffer Pool） 里，而后进行更新操做，最后再返回结果。

3、undo 日志文件

咱们都知道，在事务中，事务提交前是能够随时回滚对数据的更新的。那么是依靠什么来作的呢？

依靠的是 undo 日志文件。

undo 日志文件的使用原理：

更新数据为例： 假如你更新某行 id=100 的数据，将字段 name 由原来的“张三”改成“李四”，那么此时会将 "id=10" 和 “name=张三” 这两个关键信息写入 undo 日志文件中。 当你事务提交前须要回滚，就会从 undo 日志文件 中找到这两个关键字，而后进行更新操做的回滚。

4、redo log buffer

上面说到，全部的增删改查操做实际上是在缓冲池里面进行的，因此其实对数据的修改并无马上落实到磁盘文件里面。

那么有一个问题：在缓冲池的脏数据刷回磁盘文件中前，MySQL 宕机了怎么办？ 此时 InnoDB 存储引擎提供了一个很是重要的组件，就是 redo log buffer 组件.，它也是内存里的一块缓冲区。

redo log buffer 的使用原理：

仍是以上面的更新操做为例，当数据更新后，会记录下数据更新的的关键信息，对应的就是 redo 日志，而后写入 redo log buffer 里。

可是仍是会有一个问题，上面说到，redo log buffer 也是在内存里的。那当 MySQL 宕机时，因为内存里的全部数据都会丢失，因此缓冲池的脏数据和 redo log buffer 的日志仍是会所有丢失。 这样会形成一种状况，客户端收到更新成功的信息了，可是最后数据库里头的数据仍是没更新成功。

因此，redo log buffer 还有一个刷盘策略。正常是，当事务提交时，会将 redo log buffer 里的 redo 日志 刷回到磁盘中，这样就不用担忧，事务提交成功，可是更新数据可能会丢失的问题了。即便在 缓冲池（Buffer Pool） 的脏数据刷回磁盘前， MySQL 宕机了，也不会丢失数据，由于 MySQL 重启时能够根据磁盘中的 redo 日志 恢复以前全部脏数据的更新。

原文出处：https://www.cnblogs.com/Howinfun/p/12289860.html