就算普通索引的最后一项还是相同的，需要通过磁盘IO来读取下一页，这个时候可能是比较耗费时间的。不过因为一个数据页包含了特别多的数据，这种可能性是特别低的。
5.2 插入在我们说到插入之前，我先要跟你介绍一下change buffer这个东西。
我在上一篇文章中提到：在我们需要更新数据的时候，先把数据从磁盘读到内存中，修改这个数据，然后修改redolog，增加binlog，等内存满了之后或者redolog写满了之后，再将脏页刷回磁盘。
那么插入数据呢？
在我们新增了一条数据之后，MySQL并不会将这个插入直接写入磁盘中，而是会将这个修改写入change buffer中。
在之后有关于这个数据页的查询请求的时候，才会读取这一个数据页，然后根据change buffer中关于这一页的记录，依次更新到读取到了内存中的数据页中，这个过程称为merge。在更新完毕之后，才把查询结果返回。
这个过程对于普通索引来说是提升的非常大的。
因为merge的时候是真正进行数据更新的时刻，而change buffer的主要目的就是将记录的变更动作缓存下来，所以在一个数据页做merge之前，change buffer记录的变更越多（也就是这个页面上要更新的次数越多），收益就越大。
但是对于唯一索引来说，因为唯一索引的约束是“数据唯一”。所以还是需要找到这个数据页，判断有无冲突，才会进行插入。这样的话，change buffer不起作用。
然后我们来把change buffer与之前提到的redo log联系在一起。
比如我们需要插入两条数据，其中一条数据所在的数据页在内存中，另外一条数据所在的数据页在磁盘中（还未读入内存），且这两条数据所用到的索引是普通索引（不需要验证是否重复）。
此时，对于在数据页在内存中的插入操作，直接修改内存，对于数据页不在内存中的插入操作，将这个插入操作记录在change buffer中。随后，将这两次的操作，记录在了redo log中，然后增加binlog。当这两个日志文件都写好后，返回，操作结束。
而对于何时将内存中的脏页刷回磁盘，是另外的一个操作。
此外，这里的change buffer也同样可以被持久化，也遵循checkpoint机制，即change buffer会标记哪些记录是已经merge到数据页中，哪些还没有。
在MySQL5.5以后，除了插入操作，更新操作和删除操作，也支持使用change buffer。
写到最后首先，谢谢你能看到这里！
关于MySQL索引相关的内容，大概就是这些了。同样的，也在这篇文章中挖了很多坑没有填上。限于篇幅以及文章的连贯性，没有详细介绍。但是会在后面的文章中提到的。
如果在这篇文章中，有什么是我没有解释清楚的，又或者是我的理解出现了错误，还请留言指正，谢谢啦！
PS：如果有其他的问题，也可以在公众号找到作者。并且，所有文章第一时间会在公众号更新，欢迎来找作者玩~