详细的原因可以参考之前写的 浅入浅出 MySQL 索引
更新数据为什么下一步就是要看如何更新数据呢？因为上述的「页」的原理主要都是基于「查询」的前提在讲，看完了之后对查询的过程应该了然于胸了。接下来我们就来看看更新的时候会发生什么。
首先，如果我们插入了某条 id=100 的数据，然后再去更新的话，这条数据是一定的在 Buffer Pool 的。这句话看似是废话（我都写到数据库了那肯定存在啊）
那我换个说法，更新的时候，id=100 这条数据可能不在 Buffer Pool 中。为什么之前写入了 Buffer Pool，之后再来更新 Buffer Pool 中又没有呢？
答案是内存是有限的，我们不可能无限的向 Buffer Pool 中插入数据。熟悉 Redis 的知道，Redis 在运行时会有「过期策略」，有以下三种：
定时过期
惰性过期
定期过期
而 Buffer Pool 同样也是基于内存，同样也需要一个「过期策略」来清理掉一些不常被访问的数据，来为新的数据、热点数据腾出空间。
当然，这里的清理掉，并不是删除，而是将它们刷入磁盘
更新数据时，如果发现对应的数据不存在，就会将那个数据所在的页加载到 Buffer Pool 中来。注意，这里并不是只加载 id=100 这一行，而是其所在的一整「页」数据。
加载到 Buffer Pool 中之后，再对 Buffer Pool 中的数据进行更新。当然，这个情况对我们开发人员来说，是针对聚簇索引的。
还有另一种情况是针对「 非聚簇索引」 的。
Change Buffer很简单，当我们更新了某些字段之后，假设这些字段是组成非聚簇索引的字段，就会涉及到非聚簇索引的更新，但不巧的是该非聚簇索引所在的页不在 Buffer Pool 中。按照之前的说法，需要将对应的页（Pages）加载到 Buffer Pool 中来。
但是这里有一个很大的问题，这个二级索引可能之后**根本不会被用到，**那这样一来，刚刚昂贵的 I/O 操作就被浪费掉了。积少成多，如果每次涉及到更新二级索引发现在 Buffer Pool 中不存在，都去做 I/O 操作，那也是一个相当大的开销。
所以，InnoDB 才设计了 Change Buffer。Change Buffer 就是专门用来存储当「非聚簇索引」所在的页不在 Buffer Pool 时的更改的。
换句话说，当对应的非聚簇索引被修改并且对应的页（Pages）不在 Buffer Pool 中时，会将其改动暂存在 Change Buffer，等到其对应的页被其他的请求加载进 Buffer Pool 时，就会将 Change Buffer 中暂存的数据 和 Buffer Pool 中的数据进行合并。
当然，Change Buffer 这个设计也不是没有缺点。当 Change Buffer 中有很多的数据时，全部合并到Buffer Pool可能会花上几个小时的时间，并且在合并的期间，磁盘的 I/O 操作会比较频繁，从而导致部分的CPU资源被占用，对 MySQL 整体的性能是有影响的。
那你可能会问，难道只有被缓存的页加载到了 Buffer Pool 才会触发合并操作吗？那要是它一直没有被加载进来，Change Buffer 不就被撑爆了？很显然，InnoDB 在设计的时候考虑到了这个点。除了对应的页加载，提交事务、服务停机、服务重启都会触发合并。
Adaptive Hash自适应哈希索引（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]。
过期策略上面提到，Buffer Pool 也会有自己的过期策略，定时的将不需要的数据刷回磁盘，为后续的请求腾出空间。那么，InnoDB 是怎么知道哪些数据是不需要的呢？