mysql 索引 内存_mysql索引【第三篇】

##innodb引擎的数据是按页为单位的，当需要读一条记录时，并不是将这个记录本身从磁盘中读取出来，而是以页为单位将整个页读取到内存中，每个页默认大小为16kb

数据查询过程：  磁盘---->内存---->返回结果

数据更新过程： change buffer ---->当有查询,更新到磁盘------->内存-------->返回结果   ###这个过程不确定对不对啊，如果有不对的话  大佬可以留言指出，我是这么理解的

唯一索引和普通索引的性能差异：

在查询过程中，二者的性能几乎相同：

唯一索引，检索到数据后，由于数据的唯一性，不会继续向下查询，直接返回结果。

普通索引，检索到需要的数据后，需要继续向下检索，直到检索到不满足条件位置。需要多做的只是一次“查找和判断下一条记录”，只需要一次指针寻找和计算(多叉树模型)。

在更新过程中：

唯一索引由于数据的唯一性，所有的更新操作都要先判断这个操作是否违反唯一性约束，而这必须需要将数据页读入内存才可以判断，所以不会用到change buffer， 在数据从磁盘读入内存涉及随机IO的访问，是数据库成本最高的操作之一。

普通索引用到了change buffer，减少了随机磁盘访问，对更新的性能会有明显提升。

change buffer：当需要更新一个数据页时，如果数据页在内存就会直接更新，如果不在的话，在不影响数据一致性的前提下，会将DML操作缓存在change buffer中，就不需要从磁盘中读取这个数据页。下次需要访问这个数据页时，将数据页读入内存，然后执行change buffer中与这个页有关的操作。(持久化的数据，也会写入到磁盘)

change buffer好处：更新记录在change buffer  减少了磁盘的随机读； 数据读入内存需要占用buffer poll，用到change buffer缓存还能减少占用内存

merge：将change buffer操作写到原数据页得到最新结果，这个过程称为merge。除了访问这个数据页会触发merge外；系统后台线程也会定期merge；数据库正常关闭，也会merge

change buffer使用场景：

写多读少的业务，比如：账单、日志类

原因：读数据的时候会触发merge，读的越少，change buffer缓存的操作越多，收益就越大。而读频繁的业务会频繁触发merge，随机访问IO次数不会减少，反而增重了change  buffer维护代价。