【mysql】索引有关的问题

本文是自己学习的一些总结，比较口语化，主要是为了加强记忆，和希望与大家分享。欢迎大佬们批判和指正！

索引的数据结构，按照不同的类型来分：

数据结构：B+树，Hash，full_text

物理存储：聚簇索引、二级索引

字段特性：主键索引、唯一索引、前缀索引

字段个数：单列索引、联合索引

创建主键索引和二级索引默认使用B+树，B+树的叶子节点存放数据，非叶子节点只存放索引，叶子节点之间是双向链表相连，适用于mysql中常见的基于范围的顺序查找。

联合索引是符合最左匹配原则的，它在遇到> 、<范围匹配时会失效；而遇到>=、<=、like、between时不会失效。mysql5.6后使用了索引下推。

索引区分度：如果一个字段它的重复数据太多，比如达到30%，就算这个字段建立了索引，也不会走索引而是走全表扫描。

索引存在的缺点：

需要占用物理内存空间

是需要耗费时间去动态维护索引的，而且数据量越大耗费的时间越多。

在发生update操作时，需要去动态维护

会降低表的增删改的效率

适用场景：

字段有唯一约束的

where子句的条件字段

group by和order by字段

不适用场景：

不用于where子句的字段

字段中有大量数据是重复的

表数据太少

经常修改的字段

建议主键自增

如果主键自增的话，插入数据时追加的操作，不需要重新移动数据，效率高。因为随意插入可能插入到已经存在数据的页，那就需要移动其它数据来满足插入，甚至需要复制数据到另一个页。这个被称为页分裂。页分裂还可能造成大量的内存碎片，导致索引结构不紧凑，从而影响查询效率。

建议索引字段为not null

一个是如果索引字段为null的话，那么在优化器优化的时候，是很影响效率。在做索引，索引比较，值比较的时候都比较困难。而是null字段在记录数据的时候，会记录到记录额外信息的列表上。

索引失效

使用左或者左右模糊匹配的时候

在查询条件中，对索引列进行了计算，函数，类型转换等操作时

使用了联合索引，不遵守最左匹配规则时

where子句中，如or前面是索引列而后面不是索引列时