MySQL索引

MySQL索引

MySQL的索引底层全部是B+树

表名：user

id（auto increment）PK	name	age	sex
1	a	20	女
2	b	21	女
3	c	22	女
4	d	23	男
5	e	24	男

 一、InnoDB引擎

根据物理结构区分

聚簇索引

B+树中叶子节点存储的是当前主键id对应行的全部数据，并且叶子节点是双向链表，可以用于范围查询

非聚簇索引

叶子节点存储的是当前索引对应的列值和聚簇索引的值（一般就是主键id）

在age列上面建非聚簇索引

alter table user add index index_age(age);

根据索引列数区分

单列索引

 在age列上面建非聚簇索引

alter table user add index index_age(age);

联合索引

在多个列上面建索引

对name和age建立联合索引：alter table user add index index_age_name(name, age);

对于联合索引来说，先根据name进行排序，在name有序的情况下根据age排序，所以衍生出了最左前缀匹配原则，where中必须包含联合索引的第一个列，才可以使用该联合索引

因为如果没有name，那么age就不能保证有序（虽然这里举的例子，在name没有的时候，age也有序，但是这个属于特例，并且没有name，也不能使用index_age_name索引）

按照特征区分

主键索引（not null, unique, auto increment）

一般使用自增整型作为主键

不使用UUID作为主键的原因：①主键默认是聚簇索引，存储的时候是按照顺序排的，UUID是乱序的，在插入的时候会导致频繁的分页；②UUID所占的内存对比整型来说要更大，所以对相同高度的B+树来说，使用UUID作为主键，存储的数据更少；同时，如果对数据量相同的数据进行存储，那么UUID的树会更高，就意味着查询同一个数据，UUID作为主键的索引需要更多次数的磁盘IO

唯一索引（unique）

可以为空，但是必须保证值是唯一的

普通索引

在普通字段上面建立的索引，不要求非空，也不要求唯一

二、MyISAM存储引擎

只有非聚簇索引，没有聚簇索引，并且非聚簇索引的叶子节点直接存储的是当前行数据存储的物理地址

三、索引为什么使用B+树

哈希索引

只适合等值查询，根据查询条件进行哈希，直接进行定位，在等值查询的时候很快；但是不适合范围查询

B树索引

特点：所有节点里面都存储数据，查找的时间复杂度不确定

因为每一个节点都存储数据，所以在相等高度下的B树和B+树来说，B+树可以存储的数据更多；

并且如果存储的是等量的数据，B+树的高度要小于B树，在查找数据的时候来说，B+树的磁盘IO次数小于B树

总结

B+树存储大量数据的时候，树的高度可控，也就是磁盘IO的次数可控；并且叶子节点在上层都有冗余，所以在删除的时候，需要调整的范围可控