相信众多人关于MySQL的索引都不 生僻，索引(Index)是协助MySQL高效猎取数据的数据 构造 。

由于索引是MySQL中 比较重点的 常识，相信众多人都有 定然的了解，尤其是在面试中浮现的频率特殊高 。楼主自认为自己对MySQL的索引 有关 常识有众多了解，并且由于近期在找工作面试，所以 独自 复习了众多关于索引的 常识 。

但是，我还是图样图森破，直到我被阿里的面试官虐过之后我才晓得，自己在索引方面的 常识，只不过个小学生水平 。

以下，是我总结的一次阿里面试中关于索引有关的问题以及 常识点 。

一、索引概念、索引模型

我们是怎么聊到索引的呢，是由于我提到我们的业务量 比较大，天天大约有几百万的新数据生成，于是有了以下对话：

Q1：你们天天这么大的数据量，都是 保留在关系型数据库中吗？

A：是的，我们线上 使用的是MySQL数据库  。

Q2：天天几百万数据，一个月便是几千万了，那你们有没有关于 查问做一些优化呢？

A：我们在数据库中 创立了一些索引(我现在十分懊悔我当时说了这句话) 。

这里 能够看到，阿里的面试官并不会像有一些公司一样拿着题库一道一道的问，而是会依据面试者做过的 事件以及面试过程中的一些内容进行铺开 。

Q3：那你能说说什么是索引吗？

A：(这道题 确定难不住我啊)索引其实是一种数据 构造， 能够协助我们 快捷的检索数据库中的数据 。

Q4：那么索引具体采纳的哪种数据 构造呢？

A：(这道题我也背过)常见的MySQL重要有两种 构造：Hash索引和B+ Tree索引，我们 使用的是InnoDB引擎，默许的是B+树 。

这里我耍了一个小心机，特意说了一下索引和存储引擎有关 。 指望面试官 能够问我一些关于存储引擎的问题 。但是面试官并没有被我带跑...

Q5：既然你提到InnoDB 使用的B+ 树的索引模型，那么你晓得为何采纳B+ 树吗？这和Hash索引 比较起来有什么优缺陷吗？

A：(蓦地觉得这道题有点难，但是我还是凭借着自己的 常识储备 容易的 答复上一些)由于Hash索引底层是哈希表，哈希表是一种以key-value存储数据的 构造，所以多个数据在存储关系上是 彻底没有任何顺序关系的，所以关于区间 查问是 无奈直接通过索引 查问的，就需求全表扫描 。所以，哈希索引只 实用于等值 查问的场景 。而B+ 树是一种多路 均衡 查问树，所以他的节点是天然有序的(左子节点小于父节点、父节点小于右子节点)，所以关于 规模 查问的时候不需求做全表扫描 。

Q6：除了上面这个 规模 查问的，你还能说出 其余的一些区别吗？

A：(这个题我 答复的不好，事后百度了一下 。)

B+Tree索引和Hash索引区别？

• 哈希索引 合适等值 查问，但是 无奈进行 规模 查问；

• 哈希索引没 步骤利用索引 实现排序 ；

• 哈希索引不 支撑多列联合索引的最左匹配 规定；

• 假如有大量 反复键值的状况下，哈希索引的效率会很低，由于存在哈希碰撞问题 。

二、聚簇索引、 遮蔽索引

Q1：方才我们聊到B+ Tree ，那你晓得B+ Tree的叶子节点都 能够存哪些东西吗？

A：InnoDB的B+ Tree可能存储的是整行数据，也有可能是主键的值 。

Q2：那这两者有什么区别吗？

A：(当他问我叶子节点的时候，其实我就猜到他可能要问我聚簇索引和非聚簇索引了)在 InnoDB 里，索引B+ Tree的叶子节点存储了整行数据的是主键索引，也被称之为聚簇索引 。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引，也被称之为非聚簇索引 。

Q3：那么，聚簇索引和非聚簇索引，在 查问数据的时候有区别吗？

A：聚簇索引 查问会更快？

Q4：为何呢？

A：由于主键索引树的叶子节点直接便是我们要 查问的整行数据了 。而非主键索引的叶子节点是主键的值，查到主键的值以后，还需求再通过主键的值再进行一次 查问 。

Q5：方才你提到主键索引 查问只会查一次，而非主键索引需求回表 查问 屡次 。(后来我才晓得，原来这个过程叫做回表)是全部状况都是这样的吗？非主键索引 定然会 查问 屡次吗？

A：(额、这个问题我 答复的不好，后来我自己查 材料才晓得，通过 遮蔽索引也 能够只 查问一次 。)

遮蔽索引(covering index)指一个 查问语句的执行只用从索引中就 能够 获得， 无须从数据表中读取 。也 能够称之为实现了索引 遮蔽 。

当一条 查问语句 相符 遮蔽索引条件时，MySQL 只有求通过索引就 能够返回 查问所需求的数据，这样幸免了查到索引后再返回表操作，削减I/O 遍及效率 。

如，表covering_index_sample中有一个一般索引 idx_key1_key2(key1,key2) 。

当我们通过SQL语句：select key2 from covering_index_sample where key1 = 'keytest';的时候，就 能够通过 遮蔽索引 查问，无需回表 。

三、联合索引、最左前缀匹配

Q1：不晓得的话没关系，想问一下，你们在 创立索引的时候都会考量哪些因素呢？

A：我们一般关于 查问概率 比较高， 时常作为where条件的字段设置索引 。

Q2：那你们有用过联合索引吗？

A：用过呀，我们有对一些表中 创立过联合索引 。

Q3：那你们在 创立联合索引的时候，需求做联合索引多个字段中间顺序你们是如何 取舍的呢？

A：我们把 鉴别度最高的字段放到最前面 。

Q4：为何这么做呢？

A：(这个问题有点把我问蒙了，略微有些慌乱)这样的话可能命中率会高丝毫吧......

Q5：那你晓得最左前缀匹配吗？

A：(我蓦地想起来原来面试官是想问这个，怪自己方才为何就没想到这个呢 。)哦哦哦 。您方才问的是这个意思啊，在 创立多列索引时，我们依据业务需求，where子句中 使用最频繁的一列放在最左边，由于MySQL索引 查问会遵照最左前缀匹配的 准则，即最左优先，在检索数据时从联合索引的最左边开始匹配 。所以当我们 创立一个联合索引的时候，如(key1,key2,key3)，相当于 创立了(key1)、(key1,key2)和(key1,key2,key3)三个索引，这便是最左匹配 准则 。

固然我一开始有点懵，没有联想到最左前缀匹配，但是面试官还是 疏导了我，很友善 。

四、索引下推、 查问优化

Q1：你们线上用的MySQL是哪个版本呢？

A：我们MySQL是5.7 。

Q2：那你晓得在MySQL 5.6中，对索引做了哪些优化吗？

A：不 好心思，这个我没有去了解过 。(事后我查了一下，有一个 比较重要的 ：Index Condition Pushdown Optimization 。)

Index Condition Pushdown(索引下推)

MySQL 5.6引入了索引下推优化，默许开启， 使用SET optimizer_switch = 'index_condition_pushdown=off'; 能够将其关闭 。官方文档中给的例子和解释如下：

people表中(zipcode，lastname，firstname)组成一个索引

SELECT * FROM people WHERE zipcode='95054' AND lastname LIKE '%etrunia%' AND address LIKE '%Main Street%';

假如没有 使用索引下推技术，则MySQL会通过zipcode='95054'从存储引擎中 查问对应的数据，返回到MySQL服务端， 而后MySQL服务端基于lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来推断数据是不是 相符条件 。

假如 使用了索引下推技术，则MYSQL首先会返回 相符zipcode='95054'的索引， 而后依据lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来推断索引是不是 相符条件 。假如 相符条件，则依据该索引来对应的数据，假如不 相符，则直接reject掉 。有了索引下推优化， 能够在有like条件 查问的状况下，削减回表次数 。

Q3：你们 创立的那么多索引，到底有没有生效，或者说你们的SQL语句有没有 使用索引 查问你们有统计过吗？

A：这个还没有统计过，除非遇到慢SQL的时候我们才会去排查  。

Q4：那排查的时候，有什么 目标 能够晓得有没有走索引 查问呢？

A： 能够通过explain查看SQL语句的执行 方案，通过执行 方案来 综合索引 使用状况 。

Q5：那什么状况下会 产生明明 创立了索引，但是执行的时候并没有通过索引呢？

A：(大约记得和优化器有关，但是这个问题并没有 答复好 。)

查问优化器

一条SQL语句的 查问， 能够有不同的执行 方案，至于最后 取舍哪种 方案，需求通过优化器进行 取舍， 取舍执行成本最低的 方案 。

在一条单表 查问语句真正执行之前，MySQL的 查问优化器会找出执行该语句全部可能 使用的 方案，对照之后找出成本最低的 方案 。

这个成本最低的 方案便是所谓的执行 方案 。优化过程 大体如下：

• 依据查找条件，找出全部可能 使用的索引；

• 计算全表扫描的代价；

• 计算 使用不同索引执行 查问的代价；

• 对照各种执行 方案的代价，找出成本最低的那一个 。

Q6：哦，索引有关的 常识我们临时就问这么多吧 。你们线上数据的事务隔离级别是什么呀？

A：(后面关于事务隔离级别的问题了，就不铺开了 。)

觉得是由于我 答复的不够好，假如这几个索引问题我都会的话，他还会 诘问更多，恐怕会被虐的更惨 。

五、总结&感悟

以上，便是一次面试中关于索引 部分 常识的问题以及我 整顿的答案 。觉得这次面试过程中关于索引的 常识，自己大约 能够 答复的内容占70%左右，但是自信 彻底答对的内容只占50%左右，看来自己索引有关的 常识了解的还是不够多 。

通过这次面试，发现像阿里这种大厂关于底层 常识还是 比较看重的，我以往 认为关于索引最多也就问一下Hash和B+有什么区别，没想到最后都能问到 查问优化器上面 。

最后， 无论本次面试能不能通过，都十分 感激有这样一次机会， 能够让自己看到自己的缺乏 。通过这次面试，我也 收成了众多东西 。加油！

>>>>

参考 材料

• 极客 工夫 -《MySQL实战45讲》

• 掘金小册 -《MySQL 是 怎么运行的：从根儿上 了解 MySQL》

• 博文视点 -《高性能MySQL》

作者：Hollis

起源：Java之道(ID：javaways)

dbaplus社群 欢送 辽阔技术人员投稿，投稿邮箱：editor@dbaplus.cn