前言
前几日有个小老弟找我哭诉,挤破脑袋进Alibaba,三轮技术下来倒在了**缓存技术(Redis+MongDB)**上。听完我这小老弟的一番肺腑之言,这…缓存架构技术:Redis+MongDB,不就是阿里P7面试必跳的坑?跳不过去那就只能say godbye了,在坑里“等死”呀…紧接着…吾日三省吾身,突然发现自己掌握的好像也不咋滴,不得不回家好好“补一补”。
熬了三天三夜,四处收集缓存架构相关的:Redis+MongDB面试、实战等等笔记资料,完事之后感觉还不错呢,今天特地拿出来献宝~~
InnoDB总体结构
首先我们来看官网的一张图(图片来源于MySQL官网):
从上图中可以看出其主要分为两部分结构,一部分为内存中的结构(上图左边),一部分为磁盘中的结构(上图右边)
内存结构
InnoDB内存中的结构主要分为:Buffer Pool,Change Buffer和Log Buffer三部分。
Buffer Pool
Buffer Pool是InnoDB缓存表和索引的一块主内存区域,Buffer Pool允许直接从内存中处理经常使用的数据,从而加快处理速度,带来一定的性能提升。 但是缓存总有放满的时候,当缓存满了新来的数据怎么处理呢?Bufer Pool中采用的是LRU(least recently used,最近最少使用)算法,LRU列表中最前面存的是高频使用页,尾部放的是最少使用的页。当有新数据过来而缓存满了就会覆盖尾部数据。
假如我们有一条查询语句非常大,返回的结果集直接就超过了Buffer Pool的大小,而这种语句使用场景又是极少的,可能查询这一次之后很久不会查询,而这一次就将缓存占满了,将一些热点数据全部覆盖了。为了避免这种情况发生,InnoDB对传统的LRU算法又做了改进,将LRU列表分拆分为2个,如下图(图片来源于MySQL官网):
该算法在new子列表中保留大量页面(5/8),old子列表包含较少使用的页面(3/8);old子列表中数据可能会被覆盖,该算法具体操作如下:
-
3/8的Buffer Pool空间用于old子列表
-
列表的中点是new子列表的尾部与old子