MySQL索引底层（二）--索引底层原理
聚集索引
上次我们讲到了主键的索引,我们可以执行一下sql语句 explain select * from t_user where a = 1 我们可以看到这条sql走的是主键的索引，而在mysql的InnoDB中，主键索引则是聚集索引，数据的物理顺序与键值的逻辑（索引）顺序相同，其实就是说主键索引跟其他列的数据是存在一起的。
并且我们可以看到key_len,当前的长度是4，一般，key_len是等于所以列类型的字节长度，因为我们这条sql执行的时候是走了一个主键的索引，而主键是一个int类型，一个int类型是占4个字节，那么长度就为4。那么我们可以再验证一下：
alter table t_user add index (b,c,e);
我们现在创建了字段 b,c,e作为索引，然后我们做一个查询
explain select * from t_user where b = 3 AND d = 1
我们可以看到当前走的索引是b字段，接着key_len的长度是5，那么5是怎么来的呢？
因为此时b是索引而d不是索引，所以执行的时候，会有4个字节，又因为b是is null的所以会多占用一个字节。
现在我们将b设计为is not null，再次执行，此时的key_len就为4。
那么创建索引的本质又是什么呢，其实就是创建要给B+树的数据结构，跟我们前面所讲的主键索引是一样的， 创建主键索引，其实就是按主键排序，然后做一个B+树的数据结构，那么现在将字段b,c,e创建了索引，其实就是给b，c，e字段创建一个b+树，索引之所以能够快速查找，是因为创建索引的字段进行了排序，也就是说，创建了b字段作为索引就会给b字段的列值进行一个排序的操作。
主键只有一个字段，排序就相对简单，只需要对主键进行排序，而b,c,e三个字段要进行排序，规则其实就是先比较b的大小，如果b的字段值大小相等，那么就比较c的字段，然后按照此规则对数据进行排序。
非聚集索引
按照之前的组合规则
我们大概知道，对bce字段进行排序之后的数据结构大概是这样
那么当我们要查找a=3,b=1,e=b的时候，我们就可以直接定位到第一页的数据的第二条，但是我们可以看到当前这里只存储了4个字段的值，而我们要找的是全部字段的值，当然mysql不可能把所有列的值都存在叶子节点中，于是就在叶子节点中存储了该列的主键。
那么我们就可以利用这个组件找到一整列的数据，那么自然就有下面的对应关系。
最左前缀
EXPLAIN select * from t_user where c = 1 and e = 'A'
当我们执行上面的sql语句的时候,我们都知道这条sql不会走索引,从key_len字段中也可以看出,那么为什么没有走索引呢,因为我们创建索引的时候是指定了b,c,e三个字段创建了索引,现在我们执行这条sql的时候,我们可以把他想像成 *1A 去到数据库中查找,那么当我们这个值去我们下面这个图查找的时候
由于最左边的字段是未知的 所以根本就不知道要从左边的11A往下找还是从右边的31C往下找,毕竟最左的索引的值无法确定,那么就会造成一个全表扫描。达不到索引的意义。