最近发现，文章太长的话，包含的信息量较大， 并且需要更多的时间去阅读。而大家看文章，应该都是利用的一些碎片时间。所以我得出一个结论，文章太长不太利于大家的吸收和消化。所以我之后会减少文章的长度，2-3K字就差不多，也能够快速的阅读完。

之前写过一篇文章「简单了解InnoDB原理」，现在回过头看，其实里面只是把缓冲池（Buffer Pool），重做日志缓冲（Redo Log Buffer）、插入缓冲（Insert Buffer）和自适应哈希索引（Adaptive Hash Index）等概念简单的介绍了一下。

除此之外还聊了一下MySQL和InnoDB的日志，和两次写，总的来说算是一个入门级别的介绍，这篇文章就来详细介绍一下InnoDB的内存结构。

InnoDB内存结构

其大致结构如下图。

InnoDB内存的两个主要区域分别为Buffer Pool和Log Buffer，此处的Log Buffer目前是用于缓存Redo Log。而Buffer Pool则是MySQL或者说InnoDB中，十分重要、核心的一部分，位于主存。这也是为什么其访问数据的效率高，你可以暂时把它理解成Redis那样的内存数据库，因为我们更新和新增当然它不是，只是这样会更加方便我们理解。

Buffer Pool

通常来说，宿主机80%的内存都应该分配给Buffer Pool，因为Buffer Pool越大，其能缓存的数据就更多，更多的操作都会发生在内存，从而达到提升效率的目的。

由于其存储的数据类型和数据量非常多，Buffer Pool存储的时候一定会按照某些结构去存储，并且做了某些处理。否则获取的时候除了遍历所有数据之外，没有其他的捷径，这样的低效率操作肯定是无法支撑MySQL的高性能的。

因此，Buffer Pool被分成了很多页，这在之前的文章中也有讲过，这里不再赘述。每页可以存放很多数据，刚刚也提到了，InnoDB一定是对数据做了某些操作。

InnoDB使用了链表来组织页和页中存储的数据，页与页之间形成了双向链表，这样可以方便的从当前页跳到下一页，同时使用LRU（Least Recently Used）算法去淘汰那些不经常使用的数据。

同时，每页中的数据也通过单向链表进行链接。因为这些数据是分散到Buffer Pool中的，单向链表将这些分散的内存给连接了起来。

Log Buffer

Log Buffer用来存储那些即将被刷入到磁盘文件中的日志，例如Redo Log，该区域也是InnoDB内存的重要组成部分。Log Buffer的默认值为16M，如果我们需要进行调整的话，可以通过配置参数innodb_log_buffer_size来进行调整。

当Log Buffer如果较大，就可以存储更多的Redo Log，这样一来在事务提交之前我们就不需要将Redo Log刷入磁盘，只需要丢到Log Buffer中去即可。因此较大的Log Buffer就可以更好的支持较大的事务运行；同理，如果有事务会大量的更新、插入或者删除行，那么适当的增大Log Buffer的大小，也可以有效的减少部分磁盘I/O操作。

至于Log Buffer中的数据刷入到磁盘的频率，则可以通过参数innodb_flush_log_at_trx_commit来决定。

Buffer Pool的LRU算法

了解完了InnoDB的内存结构之后，我们来仔细看看Buffer Pool的LRU算法是如何实现将最近没有使用过的数据给过期的。

原生LRU

首先明确一点，此处的LRU算法和我们传统的LRU算法有一定的区别。为什么呢？因为实际生产环境中会存在全表扫描的情况，如果数据量较大，可能会将Buffer Pool中存下来的热点数据给全部替换出去，而这样就会导致该段时间MySQL性能断崖式下跌。

对于这种情况，MySQL有一个专用名词叫缓冲池污染。所以MySQL对LRU算法做了优化。

优化后的LRU

优化之后的链表被分成了两个部分，分别是 New Sublist 和 Old Sublist，其分别占用了 Buffer Pool 的3/4和1/4。

链表的前3/4，也就是 New Sublist 存放的是访问较为频繁的页，而后1/4也就是 Old Sublist 则是反问的不那么频繁的页。Old Sublist中的数据，会在后续Buffer Pool剩余空间不足、或者有新的页加入时被移除掉。

了解了链表的整体构造和组成之后，我们就以新页被加入到链表为起点，把整体流程走一遍。首先，一个新页被放入到Buffer Pool之后，会被插入到链表中 New Sublist 和 Old Sublist 相交的位置，该位置叫MidPoint。

该链表存储的数据来源有两部分，分别是：

• MySQL的预读线程预先加载的数据
• 用户的操作，例如Query查询

默认情况下，由用户操作影响而进入到Buffer Pool中的数据，会被立即放到链表的最前端，也就是 New Sublist 的 Head 部分。但如果是MySQL启动时预加载的数据，则会放入MidPoint中，如果这部分数据被用户访问过之后，才会放到链表的最前端。

这样一来，虽然这些页数据在链表中了，但是由于没有被访问过，就会被移动到后1/4的 Old Sublist中去，直到被清理掉。

优化Buffer Pool的配置

在实际的生产环境中，我们可以通过变更某些设置，来提升Buffer Pool运行的性能。

• 例如，我们可以分配尽量多的内存给Buffer Pool，如此就可以缓存更多的数据在内存中
• 当前有足够的内存时，就可以搞多个Buffer Pool实例，减少并发操作所带来的数据竞争
• 当我们可以预测到即将到来的大量请求时，我们可以手动的执行这部分数据的预读请求
• 我们还可以控制Buffer Pool刷数据到磁盘的频率，以根据当前MySQL的负载动态调整

那我们怎么知道当前运行的 MySQL 中 Buffer Pool 的状态呢？我们可以通过命令show engine innodb status来查看。这个命令是看 InnoDB 整体的状态的， Buffer Pool 相关的监控指标包含在了其中，在Buffer Pool And Memory模块中。

样例如下。

----------------------
BUFFER?POOL?AND?MEMORY
----------------------
Total?large?memory?allocated?137428992
Dictionary?memory?allocated?972752
Buffer?pool?size???8191
Free?buffers???????4596
Database?pages?????3585
Old?database?pages?1303
Modified?db?pages??0
Pending?reads??????0
Pending?writes:?LRU?0,?flush?list?0,?single?page?0
Pages?made?young?1171,?not?young?0
0.00?youngs/s,?0.00?non-youngs/s
Pages?read?655,?created?7139,?written?173255
0.00?reads/s,?0.00?creates/s,?0.00?writes/s
No?buffer?pool?page?gets?since?the?last?printout
Pages?read?ahead?0.00/s,?evicted?without?access?0.00/s,?Random?read?ahead?0.00/s
LRU?len:?3585,?unzip_LRU?len:?0
I/O?sum[0]:cur[0],?unzip?sum[0]:cur[0]

解释一些关键的指标所代表的含义：

• Total memory allocated：分配给 Buffer Pool 的总内存
• Dictionary memory allocated：分配给 InnoDB 数据字典的总内存
• Buffer pool size：分配给 Buffer Pool 中页的内存大小
• Free buffers：分配给 Buffer Pool 中 Free List 的内存大小
• Database pages：分配给 LRU 链表的内存大小
• Old database pages：分配给 LRU 子链表的内存大小
• Modified db pages：当前Buffer Pook中被更新的页的数量
• Pending reads：当前等待读入 Buffer Pool 的页的数量
• Pending writes LRU：当前在 LRU 链表中等待被刷入磁盘的脏页数量

都是些很常规的配置项，你可能会比较好奇什么是 Free List，Free List 中存放的都是未被使用的页。因为MySQL启动的时候，InnoDB 会预先申请一部分页。如果当前页还未被使用，就会被保存在 Free List 中。

知道了 Free List，那么你也应该知道 Flush List，里面保存的是所有的脏页，都是被更改后需要刷入到磁盘的。

自适应哈希索引

自适应哈希索引（Adaptive Hash Index）是配合Buffer Pool工作的一个功能。自适应哈希索引使得MySQL的性能更加接近于内存服务器。

如果要启用自适应哈希索引，可以通过更改配置innodb_adaptive_hash_index来开启。如果不想启用，也可以在启动的时候，通过命令行参数--skip-innodb-adaptive-hash-index来关闭。

自适应哈希索引是根据索引Key的前缀来构建的，InnoDB 有自己的监控索引的机制，当其检测到为当前某个索引页建立哈希索引能够提升效率时，就会创建对应的哈希索引。如果某张表数据量很少，其数据全部都在Buffer Pool中，那么此时自适应哈希索引就会变成我们所熟悉的指针这样一个角色。

当然，创建、维护自适应哈希索引是会带来一定的开销的，但是比起其带来的性能上的提升，这点开销可以直接忽略不计。但是，是否要开启自适应哈希索引还是需要看具体的业务情况的，例如当我们的业务特征是有大量的并发Join查询，此时访问自适应哈希索引被产生竞争。并且如果业务还使用了LIKE或者%等通配符，根本就不会用到哈希索引，那么此时自适应哈希索引反而变成了系统的负担。

所以，为了尽可能的减少并发情况下带来的竞争，InnoDB对自适应哈希索引进行了分区，每个索引都被绑定到了一个特定的分区，而每个分区都由单独的锁进行保护。其实通俗点理解，就是降低了锁的粒度。分区的数量我们可以通过配置innodb_adaptive_hash_index_parts来改变，其可配置的区间范围为[8, 512]。

Change Buffer

聊完了 Buffer Pool 中索引相关，剩下的就是 Change Buffer 了。Change Buffer是一块比较特殊的区域，其作用是用于存储那些当前不在 Buffer Pool 中的但是又被修改过的二级索引。

用流程来描述一下就是，当我们更新了非聚簇索引（二级索引）的数据时，此时应该是直接将其在Buffer Pool中的对应数据更新了即可，但是不凑巧的是，当前二级索引不在 Buffer Pool 中，此时将其从磁盘拉取到 Buffer Pool 中的话，并不是最优的解，因为该二级索引可能之后根本就不会被用到，那么刚刚昂贵的磁盘I/O操作就白费了。

所以，我们需要这么一个地方，来暂存对这些二级索引所做的改动。当被缓存的二级索引页被其他的请求加载到了Buffer Pool 中之后，就会将 Change Buffer 中缓存的数据合并到 Buffer Pool 中去。

当然，Change Buffer也不是没有缺点。当 Change Buffer 中有很多的数据时，全部合并到Buffer Pool可能会花上几个小时的时间，并且在合并的期间，磁盘的I/O操作会比较频繁，从而导致部分的CPU资源被占用。

那你可能会问，难道只有被缓存的页加载到了 Buffer Pool 才会触发合并操作吗？那要是它一直没有被加载进来，Change Buffer 不就被撑爆了？很显然，InnoDB在设计的时候考虑到了这个点。除了对应的页加载，提交事务、服务停机、服务重启都会触发合并。

欢迎微信搜索关注【SH的全栈笔记】，回复【队列】获取消息队列详解，包含基础概念解析和RocketMQ详细的源码，持续更新中。

好了以上就是本篇博客的全部内容了，如果你觉得这篇文章对你有帮助，还麻烦点个赞，关个注，分个享，留个言。