MySQL索引

什么是索引？

索引(index)是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足特定査找算法的数据结构(B+树)，这些数据结构以某种方式引用(指向)数据，这样就可以在这些数据结构上实现高级查找算法这种数据结构就是索引。

为什么要使用B+树作为索引的数据结构呢？

数据结构对比
B-Tree，B树是一种多叉路衡查找树，相对于二叉树，B树每个节点可以有多个分支，即多叉。以一颗最大度数(max-degree)为5(5阶)的b-tree为例，那这个B树每个节点最多存储4个key

B+Tree是在BTree基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用B+Tree实现其索引结构

B树与B+树对比:
①:磁盘读写代价B+树更低;②:查询效率B+树更加稳定;③:B+树便于扫库和区间查询

面试回答：

面试官:了解过索引吗?(什么是索引)
候选人:嗯，索引在项目中还是比较常见的，它是帮助MVSQL高效获取数据的数据结构，主要是用来提高数据检索的效率，降低数据库的10成本，同时通过索引列对数据进行排序，降低数据排序的成本，也能降低了CPU的消耗

面试官:索引的底层数据结构了解过嘛?
候选人:MVSQL的默认的存储引擎InnoDB采用的B+树的数据结构来存储索引，选择B+树的主要的原因是:第一阶数更多，路径更短，第二个磁盘读写代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据，第三是B+树便于扫库和区间查询，叶子节点是一个双向链表

面试官:B树和B+树的区别是什么呢?
候选人:第一:在B树中，非叶子节点和叶子节点都会存放数据，而B+树的所有的数据都会出现在叶子节点，在查询的时候，B+树查找效率更加稳定
第二:在进行范围查询的时候，B+树效率更高，因为B+树都在叶子节点存储，并且叶子节点是一个双向链表

什么是聚簇索引什么是非聚簇索引?

聚集索引选取规则:
如果存在主键，主键索引就是聚集索引。
如果不存在主键，将使用第一个唯一(UNIQUE)索引作为聚集索引。
如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。

回表查询流程图

通过二级索引找到对应的主键值，到聚集索引中查找整行数据，这个过程就是回表

面试参考回答：

面试官:什么是聚簇索引什么是非聚簇索引?

候选人:
好的~，聚簇索引主要是指数据与索引放到一块，B+树的叶子节点保存了整行数据，有且只有一个,一般情况下主键在作为聚簇索引的
非聚簇索引值的是数据与索引分开存储，B+树的叶子节点保存对应的主键，可以有多个，一般我们自己定义的索引都是非聚簇索引

面试官:知道什么是回表查询嘛?

候选人:嗯，其实跟刚才介绍的聚簇索引和非聚簇索引是有关系的，回表的意思就是通过二级索引找到对应的主键值，然后再通过主键值找到聚集索引中所对应的整行数据，这个过程就是回表
【备注:如果面试官直接问回表，则需要先介绍聚簇索引和非聚簇索引】

覆盖索引

覆盖索引是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到

select * from tb_user where id = 1 覆盖索引

select id, name from tb_user where name = 'Arm' 覆盖索引

select id, name, gender from tb_user where name = 'Arm' 非覆盖索引(需要回表查询)

MYSQL超大分页处理

在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。

因为，当在进行分页查询时，如果执行limit 9000000,10，此时需要MVSQL排序前9000010 记录，仅仅返回9000000-9000010的记录，其他记录丢弃，查询排序的代价非常大。

面试参考回答：

面试官:MYSQL超大分页怎么处理?
候选人:嗯，超大分页一般都是在数据量比较大时，我们使用了limit分页查询，并且需要对数据进行排序，这个时候效率就很低，我们可以采用覆盖索引和子查询来解决
先分页查询数据的id字段，确定了id之后，再用子查询来过滤，只查询这个id列表中的数据就可以了
因为查询id的时候，走的覆盖索引，所以效率可以提升很多

面试官:知道什么叫覆盖索引嘛?
候选人:嗯~，清楚的
覆盖索引是指select查询语句使用了索引，在返回的列，必须在索引中全部能够找到，如果我们使用id查询，它会直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。
如果按照二级索引查询数据的时候，返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select*，尽量在返回的列中都包含添加索引的字段

索引的创建原则

1).针对于数据量较大，且查询比较频繁的表建立索引。单表超过10万数据(增加用户体验)

2).针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引。

3).尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。

4).如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。           

5).尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。

6).要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。

7).如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。

面试参考回答：

面试官:索引创建原则有哪些?
候选人:嗯，这个情况有很多，不过都有一个大前提，就是表中的数据要超过10万以上，我们才会创建索引，并且添加索引的字段是查询比较频繁的字段，一般也是像作为查询条件，排序字段或分组的字段这些。
还有就是，我们通常创建索引的时候都是使用复合索引来创建，一条sgl的返回值，尽量使用覆盖索引，如果字段的区分度不高的话，我们也会把它放在组合索引后面的字段。
如果某一个字段的内容较长，我们会考虑使用前缀索引来使用，当然并不是所有的字段都要添加索引，这个索引的数量也要控制，因为添加索引也会导致新增改的速度变慢。

索引失效情况

什么情况下索引会失效?

1).违反最左前缀法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。匹配最左前缀法则，走索引:

2).范围查询右边的列，不能使用索引。

根据前面的两个字段 name，status 查询是走索引的，但是最后一个条件address 没有用到索引。

3).不要在索引列上进行运算操作， 索引将失效。

4).字符串不加单引号，造成索引失效。

由于，在查询时没有对字符串加单引号，MySQL的查询优化器，会自动的进行类型转换，造成索引失效。

5).以%开头的Like模糊查询，索引失效。如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

面试参考回答：

面试官:什么情况下索引会失效?
候选人:嗯，这个情况比较多，我说一些自己的经验，以前遇到过的
比如，索引在使用的时候没有遵循最左匹配法则，第二个是，模糊查询，如果%号在前面也会导致索引失效。如果在添加索引的字段上进行了运算操作或者类型转换也都会导致索引失效。
我们之前还遇到过一个就是，如果使用了复合索引，中间使用了范围查询，右边的条件索引也会失效所以，通常情况下，想要判断出这条sql是否有索引失效的情况，可以使用explain执行计划来分析