Mysql事务支持原理

Mysql事务支持原理

Buffer Pool简介

我们都知道MySQL中的数据都是存储在磁盘上的，那么如果每次都去磁盘上读取数据的话，那么效率肯定很低，所以在内存中就存在一个缓冲池，Buffer Pool，磁盘中的数据会被缓存到Buffer Pool中，就不需要再去磁盘中重新读取数据了

既然Buffer Pool是存在于内存中的话，那么大小肯定就有限制了，默认情况下是128M，当然相对于内存大的机器，可以适当的增加Buffer Pool的大小，对于InnoDB储存引擎而言，Buffer Pool配置可以通过 innodb_buffer_pool_size 来设置他的大小

mysqld --innodb_buffer_pool_size=8388608 --innodb_buffer_pool_instances=1 &
show variables like ‘innodb_buffer_pool%’;
注意：innodb_buffer_pool_size是整个MySQL服务器最重要的变量。
缓冲池大小必须始终等于innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数。
如果将缓冲池大小更改为不等于innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数的值，则缓冲池大小将自动调整为等于innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数的值。

数据库中的数据都是存储在一个个的数据页中，大小是16K。那么将数据页的信息放入Buffer Pool中的话，也应该是一个个页的形式，一般称之为缓存页，缓存页和数据页的大小是一一对应的

现在问题来了，既然需要将数据页放入到Buffer Pool中的缓存页，那么如何知道Buffer Pool中哪些缓存页是空的，可以用来存放数据，这里首先需要加入一个概念，就是一个缓存页除了存放数据之外，还有一个描述信息，可以理解为一篇文章的一个标题，这个描述信息中包含了数据页所属的表空间、数据页编号、缓存页在Buffer Pool中的地址等等，一个描述信息代表了一个描述数据块，也是有大小的，大概相当于一个缓存页的5%

free链表

Buffer Pool会维护一个free链表，free链表是一个双向链表。链表中的每个节点就是一个空闲数据页的描述数据块，free链表还有一个基础节点，引用了链表的头结点和尾结点，同时还存储了链表中还有多少节点，这样我们就能知道还有多少缓存页是空闲的了

free链表每个节点就是一个描述数据块，前后两个指针（free_pre和free_next）分别指向了上一个节点和下一个节点，当一个缓存页被一个数据页的数据放入了之后，就会从free链表中将这个缓存页的描述数据块给去掉，也就是分别将前后指针置为null即可

如何找到相应的表

既然维护了free链表，那怎么知道缓存中有没有我需要的数据表呢？Buffer Pool中同时会维护一个哈希表数据结构，key为表空间号 + 数据页号，value为缓存页地址，当数据库使用一个数据页的时候，就会根据提供的表名转为物理表空间号，再在这个哈希表中查询一下这个key是否存在，如果已经存在的话，就说明Buffer Pool已经有数据可以直接使用了，否则就按照上面的逻辑将硬盘数据页加载到缓存页中

flush链表

数据库中的数据以数据页的形式加载到Buffer Pool中，然后就在内存中进行各种增删改的操作，此时数据还没有写回到磁盘中，所以这些数据也就是脏数据了，那么必然会导致Buffer Pool中的缓存页中有些是脏数据，有些只是查询了而已，还不是脏数据,怎么能够保证这些脏数据能够同步到硬盘的数据文件中去。

此时又有一个链表，称之为flush链表，flush链表的数据结构和free链表的数据结构是一致的，经过增删改的缓存页就会加入flush链表的节点中，之后这些缓存页的脏数据就会被flush到磁盘上，完成数据持久化的操作

缓存页的LRU机制

之前我们提到了Buffer Pool的大小有限，那么里面的缓存页肯定也是有限的，如果缓存页都被数据页中的数据填满了，那不就无法加载新的数据进来了吗？所以我们需要一个LRU算法来淘汰一部分缓存页，Buffer Pool的做法是将缓存页上的脏数据刷入磁盘中，这样就可以空闲出来一部分的缓存页了

实现这个LRU机制依靠的是一个LRU链表，这个链表跟我们之前说过的free链表、flush链表都是一样的数据结构。只要有数据的缓存页，都会存在于LRU链表中。那们我们如何设计一个LRU算法去淘汰没用的缓存页呢？

• 假如从硬盘中刚刚读取的的数据页放到链表头，并且链表中再次被用到的的数据页都放到链表头，没动过的放在链表尾，淘汰的时候就从链表尾上的数据页开始。

上面的方案在实际情况下，可能会遇到两个问题，第一个问题是MySQL的缓存预读机制，缓存预读的意思是当从磁盘中加载一个数据页的时候，也可能会连带着把这个数据页相邻的其他数据页也加载到缓存中（局部性原理），但是其实预读的那一部分数据可能根本不会被使用到，那么链表头可能会出现一些无效的热数据；另外一个问题就是全表扫描了，这个应该就不用解释了，全表扫描也有可能产生大量无效的热数据

• 那么要怎么做才能避免无效的数据被连带着放到表头呢？其实可以将加载进来的数据页先进行冷处理，之后mysql再从缓存中拿取需要的数据，就可以淘汰掉无效的数据页了。

那么MySQL中的LRU机制到底是怎么做的呢？其实LRU链表被分为了两部分，一部分是热数据，一部分是冷数据（冷数据默认占比37%）。LRU链表的头部连接着热数据区，然后是冷数据区，最后才到链表尾部，看起是这样的
LRU链表