索引的分类：
按"数据结构"分类:B+树, Hash,全文本
按“物理存储”分类:类别索引(主键索引)和次级索引(辅助索引)
按“字段特征”分类:主键索引,唯一的索引,一般索引,前缀索引
按“字段数目”分类:单列索引,联合索引
B+tree索引
InnoDB是MySQL 5.5中的默认MySQL存储引擎,InnoDB引擎使用B+树索引
在创建表时,InnoDB存储引擎根据不同的场景选择不同的列为索引:
如果有一个主键,默认是使用主键作为集群索引键;
2如果没有主键,选择第一个非NULL列作为群索引的索引键;
3如果没有上述两个,InnoDB将自动生成一个隐含自添加ID列作为集群索引键;
B+树是一个多叉树,数据只存储在叶节点,非叶节点只存储索引,每个节点的数据存储在主键的顺序
每个母节点的索引值出现在下一个子节点的索引值中,所以叶节点包含所有索引值信息
叶节点构成链表
B+Tree存储了数以万计的数据层,只有在3-4层高度才能满足(通过比较间隔查询),这意味着从数以万计的表中查询目标数据需要最大3-4个磁盘I/O,所以B+树与B树和二进制树相比,最大的优点是查询效率很高,因为即使有很多数据,查询数据的磁盘I/O仍保持在3-4次。
为什么MySQL InnoDB选择B+tree作为索引数据结构?
B+Tree vs B Tree
B+树：
1.由于B+树不包含非叶端的实际数据,所以它只能作为索引,所以更多的键可以存储在相同的内存中
由于叶节点是项目链的链表,所以搜索和搜索范围很容易
3.B+Tree 相比于 B 树和二叉树来说，最大的优点是查询效率很高,因为即使有很多数据,查询数据的磁盘I/O仍保持在3-4次。
B树：
因为B树中的每个节点包含一个键和一个值,我们可以通过找到键的位置来根据键找到值。
然而,B+树只存储叶端点的数据,搜索必须一次性地索引,以找到树的最大深度,即叶端点的深度。
B+树 vs 分叉树
二进制树中的每个节点的子节点数仅为2,二进制树检索到目标数据的磁盘I/O次数则大;
B+树只有3个在百万级数据集下4层，只需要34I/O操作以找到数据
B+树 vs Hash表
Hash在执行等价查询时具有效率,搜索复杂度为O(1)。
但是Hash表不能做范围查询,它更适合同等查询,在发生范围查看场景时,复杂度被逆转为O(n)
群索引(主键索引)
B+Tree通常在MySQL中使用,但在实现中它与集群和非集群不同。
类别索引存储类别索引和数据在同一B+树中,因此从类别索引取得的数据比非类别索引更快
优点：
群索引具有非常快速的序列搜索和键的范围搜索速度
缺点：
插入速度很大程度上取决于插入序列,并且按照主键的插入序列是最快的方式,否则会发生页分割,严重影响性能
对于InnoDB表,我们通常定义一个增量ID列主键
更新主键的成本很高,因为它会使更新的行移动。 因此,对于InnoDB表,我们一般定义主键为未更新。
二级索引
第二阶索引B+Tree的叶节点存储主键值,而不是实际数据。
在我们的日常工作中,我们根据现实而添加的索引是辅助索引,辅助索引是需要找到主键索引的次级索引,现在找到主键索引,然后通过主键索引找到数据
因此,在查询中使用二次索引,如果查询数据可以在二次索引中查询(辅助索引字段+主键字段),那么不需要返回表,只需要寻找B+树,这是覆盖索引的过程。
如果查询数据不在二级索引中,你得先检索第二级索引,找出相应的叶节点,获取到主键值后，然后在主键索引中通过B+树查询相应的叶节点,这个过程就是回表，也就是说,你必须寻找两个B+树才能获得数据。
主键索引：
关键索引是创建在关键字段上的索引,通常在创建表时创建在一起,在表中没有超过一个关键索引,索引列的值不允许空值。
唯一索引：
单一索引创建在UNIQUE字段上,表可以包含多个单一索引,索引列的值必须是单一的,但允许有空值。
在创建表时,创建索引的唯一方法是:
普通索引：
一个共同索引是在一个共同字段上创建的索引,它既不需要一个字段主键,也不需要一个字段为UNIC
前缀索引:
前缀索引指字型字段的头几个字符的索引。
使用前缀索引的目的在于减少索引所占的存储空间,提高查询效率
联合索引
通过将多个字段结合成一个单个索引,这个索引被称为组合索引(与第二个设计模型不符,部分依赖)。
例：
通过将多个字段组合成一个单个索引,该索引被称为组合索引。
例如,在产品表中将 product_no 和 name 字段结合成一个组合索引(product_no, name)。
非叶节点使用两个字段的值作为B+Tree的键,
在输入组合索引查询数据时,首先比较 product_no字段,如果 product_no字段相同,则比较 name字段
组合索引查询的B+树由 product_no 首先排序,然后进入 product_no 并按名称字段排序同样的案例。因此，使用联合索引时，存在最左匹配原则，即, 按最左边优先顺序匹配指数.
我什么时候需要/需要创建索引?
索引的最大优点是增加查询速度,但它们也有缺点,例如:
占有物理空间是必要的,数量越大,空间就越大;
创建和维护索引需要时间,随着数据数量的增加而增加。
B+树需要动态维护以维持索引顺序。
什么时候适当使用索引?
1.具有独特的特征的词汇,如商品编码;
2.经常使用的WHERE查询条件的字段,可以提高整个表的查询速度,如果查询条件不是字段,则可以创建组合索引。
3.它经常用于 GROUP BY 和 ORDER BY 的字段,所以你不需要再查询,因为我们都知道B+Tree的记录在创建索引后都很好地排序。
什么时候需要创建索引?
在没有使用的字段中,索引的值是快速定位。如果没有定位的字段没有创建,索引通常是不需要的,因为索引占有物理空间。
这个领域有许多重复数据,不需要创建索引,表数据也不太小也不必要
3.经常更新的字段不需要创建目录,维护目录是昂贵的,经常重构目录会影响数据库性能
索引优化的方法？
前缀索引优化：
使用前缀索引可以减少索引字段的大小,增加在一个索引页面中存储的索引值,有效地提高索引的查询速度。 当一些大字符串的字段被用作索引时,使用前缀索引可以帮助我们减少索引项的大小
主要关键指标是最佳自我增强:
innoDB创建了一个主键索引器,它考虑聚类索引,数据存储在B+树叶节点上。也就是说，同一叶节点的所有数据都存储在主键顺序中,如果我们使用自我增强键,每次将新数据插入时,它将按照顺序添加到当前索引节点,不需要移动现有的数据,
索引最好设置为 NOT NULL
为了更好地使用索引,索引列必须设置为 NOT NULL约束
存在NULL索引列将使优化器在选择索引时更加复杂
防止索引失效
索引失败时:
当我们使用左或右模糊匹配时,例如%xx或%xx,这两个方法都会导致索引失败;
为了正确使用组合索引,必须遵循最左匹配原则,即以最左优先的方式匹配索引,否则将导致索引失败。
在WHERE子项中,如果OR之前的条件列为搜索列,OR之后的条件列不是搜索列,那么搜索无效。
参考：
https://xiaolincoding.com/mysql/index/index_interview.html#%E7%B4%A2%E5%BC%95%E7%9A%84%E5%88%86%E7%B1%BB