GitHub 4.8k Star 的Java工程师成神之路 ,不来了解一下吗?git
GitHub 4.8k Star 的Java工程师成神之路 ,真的不来了解一下吗?github
GitHub 4.8k Star 的Java工程师成神之路 ,真的肯定不来了解一下吗?面试
本文来自一位不肯意透露姓名的粉丝投稿sql
相信不少人对于MySQL的索引都不陌生,索引(Index)是帮助MySQL高效获取数据的数据结构。数据库
由于索引是MySQL中比较重点的知识,相信不少人都有必定的了解,尤为是在面试中出现的频率特别高。楼主自认为本身对MySQL的索引相关知识有不少了解,并且由于最近在找工做面试,因此单独复习了不少关于索引的知识。markdown
可是,我仍是图样图森破,直到我被阿里的面试官虐过以后我才知道,本身在索引方面的知识,只是个小学生水平。数据结构
如下,是我总结的一次阿里面试中关于索引有关的问题以及知识点。oop
咱们是怎么聊到索引的呢,是由于我提到咱们的业务量比较大,天天大概有几百万的新数据生成,因而有了如下对话:优化
面试官:大家天天这么大的数据量,都是保存在关系型数据库中吗?spa
我:是的,咱们线上使用的是MySQL数据库
面试官:天天几百万数据,一个月就是几千万了,那大家有没有对于查询作一些优化呢?
我:咱们在数据库中建立了一些索引(我如今很是后悔我当时说了这句话)。
这里能够看到,阿里的面试官并不会像有一些公司同样拿着题库一道一道的问,而是会根据面试者作过的事情以及面试过程当中的一些内容进行展开。
面试官:那你能说说什么是索引吗?
我:(这道题确定难不住我啊)索引实际上是一种数据结构,可以帮助咱们快速的检索数据库中的数据。
面试官:那么索引具体采用的哪一种数据结构呢?
我:(这道题我也背过)常见的MySQL主要有两种结构:Hash索引和B+ Tree索引,咱们使用的是InnoDB引擎,默认的是B+树。
这里我耍了一个当心机,特地说了一下索引和存储引擎有关。但愿面试官能够问我一些关于存储引擎的问题。
面试官:既然你提到InnoDB使用的B+ Tree的索引模型,那么你知道为何采用B+ 树吗?这和Hash索引比较起来有什么优缺点吗?
我:(忽然以为这道题有点难,可是我仍是凭借着本身的知识储备简单的回答上一些)由于Hash索引底层是哈希表,哈希表是一种以key-value存储数据的结构,因此多个数据在存储关系上是彻底没有任何顺序关系的,因此,对于区间查询是没法直接经过索引查询的,就须要全表扫描。因此,哈希索引只适用于等值查询的场景。而B+ Tree是一种多路平衡查询树,因此他的节点是自然有序的(左子节点小于父节点、父节点小于右子节点),因此对于范围查询的时候不须要作全表扫描。
面试官:除了上面这个范围查询的,你还能说出其余的一些区别吗?
我:(这个题我回答的很差,过后百度了一下)
科普时间:B+ Tree索引和Hash索引区别 哈希索引适合等值查询,可是不没法进行范围查询 哈希索引没办法利用索引完成排序 哈希索引不支持多列联合索引的最左匹配规则 若是有大量重复键值得状况下,哈希索引的效率会很低,由于存在哈希碰撞问题
面试官:刚刚咱们聊到B+ Tree ,那你知道B+ Tree的叶子节点均可以存哪些东西吗?
我:InnoDB的B+ Tree可能存储的是整行数据,也有多是主键的值。
面试官:那这二者有什么区别吗? 我:(当他问我叶子节点的时候,其实我就猜到他可能要问我聚簇索引和非聚簇索引了)在 InnoDB 里,索引B+ Tree的叶子节点存储了整行数据的是主键索引,也被称之为聚簇索引。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引,也被称之为非聚簇索引。 面试官:那么,聚簇索引和非聚簇索引,在查询数据的时候有区别吗?
我:聚簇索引查询会更快?
面试官:为何呢?
我:由于主键索引树的叶子节点直接就是咱们要查询的整行数据了。而非主键索引的叶子节点是主键的值,查到主键的值之后,还须要再经过主键的值再进行一次查询。
面试官:刚刚你提到主键索引查询只会查一次,而非主键索引须要回表查询屡次。(后来我才知道,原来这个过程叫作回表)是全部状况都是这样的吗?非主键索引必定会查询屡次吗?
我:(额、这个问题我回答的很差,后来我本身查资料才知道,经过覆盖索引也能够只查询一次)
科普时间——覆盖索引 覆盖索引(covering index)指一个查询语句的执行只用从索引中就可以取得,没必要从数据表中读取。也能够称之为实现了索引覆盖。 当一条查询语句符合覆盖索引条件时,MySQL只须要经过索引就能够返回查询所须要的数据,这样避免了查到索引后再返回表操做,减小I/O提升效率。 如,表covering_index_sample中有一个普通索引 idx_key1_key2(key1,key2)。当咱们经过SQL语句:select key2 from covering_index_sample where key1 = 'keytest';的时候,就能够经过覆盖索引查询,无需回表。
面试官:不知道的话不要紧,想问一下,大家在建立索引的时候都会考虑哪些因素呢?
我:咱们通常对于查询几率比较高,常常做为where条件的字段设置索引
面试官:那大家有用过联合索引吗?
我:用过呀,咱们有对一些表中建立过联合索引。
面试官:那大家在建立联合索引的时候,须要作联合索引多个字段之间顺序大家是如何选择的呢?
我:咱们把识别度最高的字段放到最前面。
面试官:为何这么作呢?
我:(这个问题有点把我问蒙了,稍微有些慌乱)这样的话可能命中率会高一点吧。。。
面试官:那你知道最左前缀匹配吗?
我:(我忽然想起来原来面试官是想问这个,怪本身刚刚为何就没想到这个呢。)哦哦哦。您刚刚问的是这个意思啊,在建立多列索引时,咱们根据业务需求,where子句中使用最频繁的一列放在最左边,由于MySQL索引查询会遵循最左前缀匹配的原则,即最左优先,在检索数据时从联合索引的最左边开始匹配。因此当咱们建立一个联合索引的时候,如(key1,key2,key3),至关于建立了(key1)、(key1,key2)和(key1,key2,key3)三个索引,这就是最左匹配原则。
虽然我一开始有点懵,没有联想到最左前缀匹配,可是面试官仍是引导了我。很友善。
面试官:大家线上用的MySQL是哪一个版本啊呢?
我:咱们MySQL是5.7
面试官:那你知道在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条件查询的状况下,减小回表次数。
面试官:大家建立的那么多索引,到底有没有生效,或者说大家的SQL语句有没有使用索引查询大家有统计过吗?
我:这个尚未统计过,除非遇到慢SQL的时候咱们才会去排查
面试官:那排查的时候,有什么手段能够知道有没有走索引查询呢?
我:能够经过explain查看sql语句的执行计划,经过执行计划来分析索引使用状况
面试官:那什么状况下会发生明明建立了索引,可是执行的时候并无经过索引呢?
我:(依稀记得和优化器有关,可是这个问题并无回答好)
科普时间——查询优化器 一条SQL语句的查询,能够有不一样的执行方案,至于最终选择哪一种方案,须要经过优化器进行选择,选择执行成本最低的方案。 在一条单表查询语句真正执行以前,MySQL的查询优化器会找出执行该语句全部可能使用的方案,对比以后找出成本最低的方案。这个成本最低的方案就是所谓的执行计划。 优化过程大体以下: 一、根据搜索条件,找出全部可能使用的索引 二、计算全表扫描的代价 三、计算使用不一样索引执行查询的代价 四、对比各类执行方案的代价,找出成本最低的那一个
面试官:哦,索引有关的知识咱们暂时就问这么多吧。大家线上数据的事务隔离级别是什么呀?
我:(后面关于事务隔离级别的问题了,就不展开了)
感受是由于我回答的不够好,若是这几个索引问题我都会的话,他还会追问更多,恐怕会被虐的更惨
以上,就是一次面试中关于索引部分知识的问题以及我整理的答案。感受此次面试过程当中关于索引的知识,本身大概可以回答的内容占70%左右,可是自信彻底答对的内容只占50%左右,看来本身索引有关的知识了解的仍是不够多。
经过此次面试,发现像阿里这种大厂对于底层知识仍是比较看重的,我之前觉得关于索引最多也就问一下Hash和B+有什么区别,没想到最后都能问到查询优化器上面。
最后,无论本次面试能不能经过,都很是感谢有这样一次机会,可让本身看到本身的不足。经过此次面试,我也收获了不少东西。加油!