深入理解MySql之B+索引

索引的设计思路：

去遍历所有数据页，再去遍历页中的链表太费时间。

所以考虑再建立数据页的目录，快速查找数据页面，每个目录项包括两部分，该页内的最小主键，页号

新分配的数据页编号可能并不是连续的，也就是说我们使用的这些页在存储空间里可能并不挨着。

下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值

把几个目录项在物理存贮上连续存贮，比如数组，所以查找的过程就是先根据主键二分查找到页，再二分查找具体记录

上述设计的缺点：
随表中记录数量的增多，需要非常大的连续的存储空间才能把所有的目录项都放下，这对记录数量非常多的表是不现实的；杀掉一个页，后续所有都要调整

解决方案:复用了之前存储用户记录的数据页来存储目录项，为了和用户记录做一下区分，我们把这些用来表示目录项的记录称为目录项记录,根据record_type来区分是用户记录还是目录项记录。目录项记录只有主键值和页的编号两个列，而普通的用户记录的列是用户自己定义的，可能包含很多列。

当然目标项记录页也是需要多个双向链表串起来的

现在的查找过程：

先确定目标项记录页，再到存储目录项记录的页，也就是页30中通过二分法快速定位到对应目录项，因为12 < 20 <209，所以定位到对应的记录所在的页就是页9

再到存储用户记录的页9中根据二分法快速定位到主键值为20的用户记录。

当然随着数据量的增加，还会继续有多的目录创建，即大目录里镶嵌小目录，最后就形成树状图，即B+树

实际用户记录其实都存放在B+树的最底层的节点上，这些节点也被称为叶子节点或叶节点，其余用来存放目录项的节点称为非叶子节点或者内节点，其中B+树最上边的那个节点也称为根节点。

InnoDB存储引擎会自动的为我们创建聚簇索引。另外有趣的一点是，在InnoDB存储引擎中，聚簇索引就是数据的存储方式（所有的用户记录都存储在了叶子节点），也就是所谓的索引即数据，数据即索引。

上边介绍的聚簇索引只能在搜索条件是主键值时才能发挥作用，因为B+树中的数据都是按照主键进行排序的。

二级索引
若是以别的列作为查询条件，此时，可以以别的列作为排序条件构建B+树，此时叶子节点存储的并不是完整的用户记录（太占地方），而只是c2列+主键这两个列的值。所以通过C2的排序规则找到后，还要继续用查到的主键去聚簇索引中回表查询完整记录，这种B+树也就是二级索引

联合索引

我们也可以同时以多个列的大小作为排序规则，也就是同时为多个列建立索引，比方说我们想让B+树按照c2和c3列的大小进行排序，这个包含两层含义：

先把各个记录和页按照c2列进行排序。
在记录的c2列相同的情况下，采用c3列进行排序

一个B+树索引的根节点自诞生之日起，便不会再移动。从上到下创建索引，二级索引和联合索引中必须有主键的原因也在于此，若是没有主键，以C2为排序规则，一样的C2值怎么分配到两个页面中呢，所以需要加入主键保证在B+树的同一层内节点的目录项记录除页号这个字段以外是唯一的。

InnoDB中索引即数据，也就是聚簇索引的那棵B+树的叶子节点中已经把所有完整的用户记录都包含了，而MyISAM的索引方案虽然也使用树形结构，但是却将索引和数据分开存储：

MyISAM中建立的索引相当于全部都是二级索引！

InnoDB存储引擎会自动为主键（如果没有它会自动帮我们添加）建立聚簇索引，聚簇索引的叶子节点包含完整的用户记录。

我们可以为自己感兴趣的列建立二级索引，