qq_25046827的博客

我们知道数据的修改首先是在Buffer Pool中进行的，之后再定时刷到磁盘中。那么如果在事务提交后还没刷新到磁盘中，系统就崩溃了，那么此时数据就丢失了，这就不满足事务的持久性了。而如果我们考虑每次提交之后，都同步将事务中所有的页面刷新到磁盘，这样确实可以保证持久性，但是我们只是希望这个提交的事务的修改不会丢失，即使崩溃在重启后也可能进行恢复，那么其实完全没有必要在每次提交的时候就将页面全部刷回去，**只需要对修改的内容简单的做一个记录就可以了**。

以这个算法为核心，InnoDB维护了一个LRU链表，如果页不在Buffer Pool中，在把该页从磁盘加载到Buffer Pool的时候，就把该缓冲页对应的控制块作为节点添加到LRU链表的头部，如果使用到链表中的某个页时也将其移动到链表头部。在数据库中进行读取页的操作，首先将从磁盘读到的页存放在缓冲池中，这个过程称为将页“FIX”在缓冲池中，在下一次读取相同的页时，首先判断该页是否存在缓冲池中，如果存在则被命中，直接读取，否则读取磁盘上的页。当从磁盘上读取到一个页时，我们需要将其放置在空闲的缓冲页中。

前面我们讲到了区和段的概念，也讲到了它们对应的XDES Entry结构和INODE Entry结构以及各种以XDES Entry为节点的链表。我们知道了页的申请需要用到这些结构，那这些结构存放在那呢，这就需要了解整个表空间的结构了。表空间实际上就是由许许多多的页组成的，为了更好的管理页，我们引入了区的概念，对于16KB的页而言，64个连续的页面就是一个区。而**表空间可以看为是由若干个连续的区组成，其中每256个区被划分成了一组（同样是为了更好的管理），每个组中的前几个页面会负责维护这个组的一些信息。

因为 MySQL 插件式存储引擎的体系结构的关系，MySQL 数据的存储是根据表的， 每个表都会有与之对应的文件。在 MySQL 8 之前不论表采用何种存储引擎，都有一个以 frm 为后缀名的文件，记录了该表的表结构定义。MySQL 8之后 InnoDB 存储引擎的表定义结构整合到 ibd 文件中，而 MyISAM 的 frm 文件变为 sdi 文件。

它从 last Checkpoint 对应的 LSN 开始扫描 redo-log 日志，并将其应用到 buffer-pool 中，直到 last Checkpoint 对应的 LSN 等于 log flushed up to 对应的 LSN （也就是 redo-log 磁盘上存储的 LSN 值)，则恢复完成。由于页的操作首先都是在缓冲池中完成的，那么如果一条DML语句改变了页中的记录，那么此时页就是脏的，即缓冲池中页的版本要比磁盘的新。那么数据库需要将新版本的页刷新到磁盘。所以 InnoDB 存储引擎。