MYSQL INDEX 是那么简单的吗？

平时我们在使用INDEX的时候都是那么理所应当，而原理估计了解的人不是太多。今天来说说MYSQL 的索引的一些东西，或许你已经知道了，或许你还不知道，follow me .

自从MYSQL 5.7 后，INDEX的建立不在是从顶向下的方式，而是自下向上的方式来建立索引。

一般建立一个二级索引需要的步骤

1 从聚集索引中读取相关的数据条目来进行二级索引的构建

2 进行与索引相关的归并排序

3 插入二级索引需要的记录

而传统的索引构建的方法自上而下，他会产生很多的页面的分割和页面的合并的操作，而这样的操作对于建立索引的代价是比较昂贵的。MYSQL 5.7 构建索引的方法变为从下往上的方式来进行。(用图来演示)

1 插入一个页 叶子节点

2 当叶子节点插满后，将叶子节点的指针插入到父节点

3 然后产生另外一个叶子节点，在将数据插满后连接到父节点，周而复始

4 通过上面周而复始的操作，就产生了二级的索引

但问题是大部分数据库都有一个填充因子（有的数据库不这么叫），在MYSQL 里面默认的比率是 100， 而聚簇索引则以默认 百分之6的填充因子进行设置，也就是说一个页面有百分之6是空的，为未来的DML操作进行保留。

这就牵扯到一个事情，即使默认的索引填充率应该怎么设置的问题，如果设置成80%，就是有20%的空间要留给未来的数据升级使用。

一般来说可以根据具体的数据库的大部分表的更新的度来进行 innodb_fill_factor 来进行设置。一般从 70% -90% 不等来设计，如果表是静态表，基本上不更新则 90% 即可，如果经常更新，并且有些字段的值的变动较大，则可以考虑70%。后续中的页的在拆分和合并的操作。

所以调整innodb_fill_factor 操作的主要目的

1 防止也的 splits 和 merges

2 不要经常进行数据插入位置的research

3 如果没有splits 和 merges 则 redo log 的压力就会比较小，不会进行redo log的操作

缺点也是显而易见的，就是会浪费空间。