I believe many people are not familiar with for MySQL index, the index (Index) to help MySQL efficiently get the data structure of the data.
Because the index is the more focused MySQL knowledge, I believe many people have some understanding, especially the frequency of occurrence in the interview is particularly high. The landlord thinks they have a lot of knowledge of the index MySQL knowledge, but also because of the recent interviewing for a job, so a lot of knowledge about the individual review of the index.
However, I still drawing Tucson break until after I had been Ali child interviewer, I learned that my knowledge of indexing terms, but a primary school level.
The following is a summary of my interview Ali on index-related issues as well as knowledge points.
01 Index concept / model Index
How we talk to index it, because I mentioned our business than larger, probably every day millions of new data generated, so have the following dialogue:
(1) Interviewer: Do you such a large amount of data every day, are stored in a relational database do?
I: Yes, we are using the MySQL database online
(2) Interviewer: millions of data every day, a month that tens of millions, and that you have not done some optimization for query it?
I: We created a number of indexes in the database (I am very sorry I said this sentence).
Here you can see, Ali interviewer does not hold an exam like the one asked some companies, but will be expanded according to the interviewer done before and some of the contents of the interview process.
(3) Interviewer: Can you talk about what is the index it?
:( I'm sure this question is difficult to live my ah) index is actually a data structure that can help us to quickly retrieve the data in the database.
(4) Interviewer: So what kind of indexing the data structure of the specific use of it?
I :( This question I have memorized) common MySQL There are two main structures: Hash index and B + Tree indexing, we use the InnoDB engine, the default is B + tree.
Here I am playing a careful machine, specifically said about the indexing and storage engine related. The interviewer may want to ask me some questions about the storage engine.
(5) Interviewer: Now that you mention B + Tree indexing model InnoDB uses, then you know why the use of B + trees do? This Hash index compared to what advantages and disadvantages it?
:( I suddenly felt This question is a bit difficult, but I still virtue of their knowledge base to answer some simple) Hash index because the underlying structure is a hash table, hash table is a kind of key-value store data, so more data on the storage relationship is absolutely no relationship between the order, so for interval queries are not directly indexed by the query, you need full table scan. Therefore, the hash index is only applicable to the equivalent scene queries. The B + Tree is a multi-channel balance query tree, so he is the natural order of nodes (left child node is less than the parent, the parent node is less than the right child node), so for the time scope of the query does not need to do a full table scan.
(6) Interviewer: In addition to the above this range queries, you can tell some other difference?
:( I answer this question I have is not good, after Baidu a bit)
Science Time: B + Tree indexes and hash Hash index difference between the equivalent index for the query, but not impossible hash index range query can not use the index to complete the sort hash indexes do not support multi-column leftmost matching rules, if a large number of joint index It is worth repeating key case, hash index is inefficient because of a hash collision
02 clustered indexes / coverage index
(1) Interviewer: We just talked to B + Tree, you know B + Tree leaf nodes are things which can keep it?
I: InnoDB the B + Tree is possible to store the entire row of data, there may be the primary key value.
(2) Interviewer: What is the difference that both of you?
I :( when he asked me a leaf node when in fact I guess he may have to ask me a clustered index and non-clustered indexes a) In InnoDB, the index B + Tree leaf node stores the entire row of data is a primary key index, also called clustered indexes. And the index B + Tree leaf node stores the non-primary key value of the primary key index, also known as non-clustered index.
(3) Interviewer: So, clustered index and non-clustered indexes, there a difference in the query data when?
I: clustered index query faster
(4) Interviewer: Why?
Me: Because the primary key index tree leaf node is directly entire row of data we want to query. Rather than the primary key index leaf node is the value of the primary key, the primary key values found later, still need to make another query by the primary key value.
(5) Interviewer: You just mentioned the primary key index query will only check once, rather than the primary key index queries need to return to the table several times. (Later I learned that the original process called back to the table) are all situations that right? Non-primary key index will query multiple times it?
我：（额、这个问题我回答的不好，后来我自己查资料才知道，通过覆盖索引也可以只查询一次）
科普时间——覆盖索引 覆盖索引（covering index）指一个查询语句的执行只用从索引中就能够取得，不必从数据表中读取。也可以称之为实现了索引覆盖。 当一条查询语句符合覆盖索引条件时，MySQL只需要通过索引就可以返回查询所需要的数据，这样避免了查到索引后再返回表操作，减少I/O提高效率。 如，表covering_index_sample中有一个普通索引 idx_key1_key2(key1,key2)。当我们通过SQL语句：select key2 from covering_index_sample where key1 = 'keytest';的时候，就可以通过覆盖索引查询，无需回表。
03 联合索引/最左前缀匹配
（1）面试官：不知道的话没关系，想问一下，你们在创建索引的时候都会考虑哪些因素呢？
我：我们一般对于查询概率比较高，经常作为where条件的字段设置索引
（2）面试官：那你们有用过联合索引吗？
我：用过呀，我们有对一些表中创建过联合索引。
（3）面试官：那你们在创建联合索引的时候，需要做联合索引多个字段之间顺序你们是如何选择的呢？
我：我们把识别度最高的字段放到最前面。
（4）面试官：为什么这么做呢？
我：（这个问题有点把我问蒙了，稍微有些慌乱）这样的话可能命中率会高一点吧。。。
（5）面试官：那你知道最左前缀匹配吗？
我：（我突然想起来原来面试官是想问这个，怪自己刚刚为什么就没想到这个呢。）哦哦哦。您刚刚问的是这个意思啊，在创建多列索引时，我们根据业务需求，where子句中使用最频繁的一列放在最左边，因为MySQL索引查询会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。所以当我们创建一个联合索引的时候，如(key1,key2,key3)，相当于创建了（key1）、(key1,key2)和(key1,key2,key3)三个索引，这就是最左匹配原则。
虽然我一开始有点懵，没有联想到最左前缀匹配，但是面试官还是引导了我，很友善。
04 索引下推、查询优化
（1）面试官：你们线上用的MySQL是哪个版本啊呢？
我：我们MySQL是5.7
（2）面试官：那你知道在MySQL 5.6中，对索引做了哪些优化吗？
我：不好意思，这个我没有去了解过。（事后我查了一下，有一个比较重要的 ：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条件查询的情况下，减少回表次数。
（3）面试官：你们创建的那么多索引，到底有没有生效，或者说你们的SQL语句有没有使用索引查询你们有统计过吗？
我：这个还没有统计过，除非遇到慢SQL的时候我们才会去排查
（4）面试官：那排查的时候，有什么手段可以知道有没有走索引查询呢？
我：可以通过explain查看sql语句的执行计划，通过执行计划来分析索引使用情况
（5）面试官：那什么情况下会发生明明创建了索引，但是执行的时候并没有通过索引呢？
我：（依稀记得和优化器有关，但是这个问题并没有回答好）
科普时间——查询优化器 一条SQL语句的查询，可以有不同的执行方案，至于最终选择哪种方案，需要通过优化器进行选择，选择执行成本最低的方案。 在一条单表查询语句真正执行之前，MySQL的查询优化器会找出执行该语句所有可能使用的方案，对比之后找出成本最低的方案。这个成本最低的方案就是所谓的执行计划。 优化过程大致如下：
① 根据搜索条件，找出所有可能使用的索引
② 计算全表扫描的代价
③ 计算使用不同索引执行查询的代价 4、对比各种执行方案的代价，找出成本最低的那一个
（6）面试官：哦，索引有关的知识我们暂时就问这么多吧。你们线上数据的事务隔离级别是什么呀？
我：(后面关于事务隔离级别的问题了，就不展开了)
感觉是因为我回答的不够好，如果这几个索引问题我都会的话，他还会追问更多，恐怕会被虐的更惨
05 总结&感悟
以上，就是一次面试中关于索引部分知识的问题以及我整理的答案。感觉这次面试过程中关于索引的知识，自己大概能够回答的内容占70%左右，但是自信完全答对的内容只占50%左右，看来自己索引有关的知识了解的还是不够多。
通过这次面试，发现像阿里这种大厂对于底层知识还是比较看重的，我以前以为关于索引最多也就问一下Hash和B+有什么区别，没想到最后都能问到查询优化器上面。
最后，不管本次面试能不能通过，都非常感谢有这样一次机会，可以让自己看到自己的不足。通过这次面试，我也收获了很多东西。加油！