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链表