建索引是我们在日常开发中都会遇到的问题，但是很多人都不明白索引应该如何建才能对查询起到帮助作用，有的只是为了建索引而建索引。这篇文章是我在看过一些索引的资料后总结的一些建索引的建议，如果有不对的地方请纠正指出。
一、了解下B+树索引的结构
B+树索引的一些特点：
1.B+树索引的结构本质就是一棵树；
2.在mysql索引中B+树的非叶子节点是不存储具体的数据的，只存储键值，叶子节点才存储具体的数据；
3.B+树的节点存储的键值从左到右是递增的（这样查找起来快）；
4.B+树的子节点间是由链表进行链接的；
二、B+树索引又分为聚集索引和非聚集索引
聚集索引指的是叶子节点中存储一行完整记录的索引，他是按照某个主键顺序排列的。如果我们没有建立唯一索引，innodb会默认帮我们建立主键索引。
而非聚集索引虽然也是按照某一个字段进行排序的，但是叶子节点存储的却是与聚集索引主键的关联关系，通过这个关联关系我们就可以去找到对应的聚集索引的数据了。
下面这张图与上图不同的是这个非聚集索引的叶子节点存储的就是与聚集索引的主键的关联关系。
三、联合索引的结构如何
单个索引就是上面的这种树，如果是联合索引树的结构又是怎么样的呢
假设我们建了一张表t，包含a,b,c,d四个字段，a是主键，index(b,c,d)剩下的b,c,d是联合索引，b是联合索引中的第一个字段，c是联合索引中的第二个字段，c是联合索引中的第三个字段。那么下面这张表的b,c,d联合索引的B+树就如上图所示。
四、最左前缀匹配原则
当我们知道联合索引的结构如上图所示的时候，应该就能够猜到什么是最左前缀匹配原则了吧。
就是我们where条件中只有当含有b的查询条件时才能够走索引，如果没有b条件就用不到，因为在联合索引中非叶子节点只有b是有序的。当然有些含有b的查询条件也用不到，比如like %? 或者用 or条件。
五、索引覆盖
假设我们的表又多了一个字段，如下图所示，一个varchar类型的字段e，我们想通过条件b来查询e，那么我们只能够走上面的非聚集索引，查出来的数据只能找到相对应的a的值，然后再通过a的值去查聚集索引，获得e的值。这种通过非聚集索引再查聚集索引的方式叫做回表。
这样查询两次会比较耗时，有没有方法避免呢？
如果把字段e也加入上面那个非聚集索引是不是就可以不需要回表就能够查出来想要的数据了，这种方式叫做索引覆盖。
索引覆盖也有缺点：一是浪费空间，二是每次更新数据都要去更新索引，也会耗时。
六、索引是不是越多越好呢？
别忘了我们在更新数据时也是需要去更新索引的，所以索引的多少对于数据库的性能还是有影响的，所以我们建索引时应该尽量符合那些高频查询的语句，对于那些查得少的语句就不需要建了。
附上 一篇mysql 的explain语句的语义解释文章
3748
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
