《MySQL面试小抄》索引考点一面总结

《MySQL面试小抄》索引考点一面总结

我是肥哥，一名不专业的面试官！

我是囧囧，一名积极找工做的小菜鸟，囧囧表示：面试最怕的就是面试官问的知识点太笼统，本身没法快速定位到关键问题点！！！

---

本期主要面试考点

面试官考点之谈谈你对索引的理解？

面试官考点之解释一下计算机层面索引快的缘由？

面试官考点之为何不使用哈希结构做为索引结构？

面试官考点之为何不使用二叉树做为索引结构？

面试官考点之为何不使用B-Tree，而是B+Tree？

面试官考点之索引是加速查询，那么是否应该给表尽量创建多的索引列？

---

---

面试官考点之谈谈你对索引的理解？

谈到索引，最早联想到的大概就是字典目录，根据MySQL官方定义，索引是用来帮助MySQL高效获取数据的一种数据结构。

本质上：索引是一种有序的快速查找的数据结构，用来快速高效的查找数据。

简单来讲，能够类比字典目录，火车车次表。

面试官考点之解释一下计算机层面索引快的缘由？

计算机从磁盘获取数据，加载到内存期间，通常都要经历3个常规的耗时过程：

一、寻道（时间）：肯定要读的数据在哪一个磁道耗费的时间
二、旋转延迟（时间）：肯定要读的数据在磁道上的哪一个扇区耗费的时间
三、数据传输（时间）：数据加载到内存耗费的时间

每次加载数据，咱们称其为一次磁盘IO，每一次IO操做耗费时间 = 寻道 + 旋转延迟 + 数据传输（时间短暂，能够忽略不计）。

事实上实际加载数据到内存的时间很是短暂，一次IO操做主要的耗时来自寻道和旋转延迟。

整体来讲，通常一次IO操做，耗时大概只有几ms。假如是4ms，虽然看起来很短暂，可是数据库百万级别的数据加载一遍，就须要4000s，对于一个系统来讲，简直是毁灭级别的。

咱们须要的就是减小磁盘IO的次数，这也是使用索引的意义所在！！！索引可以保证在亿级别的数据，只须要2~4次磁盘IO，这无疑是个福音！

面试官考点之为何不使用哈希结构做为索引结构？

通常正常的业务场景中，一般查询多数是范围查询 相似：

select id, name, age from sys_user where age between 18 and 28;

哈希结构做为索引，那么存储引擎就会为每一行表记录计算出哈希值，哈希索引存储的就是HASH码；

HASH码直接随机生成，并无规律

没有规律的HASH码，致使数据随机分布存储，这就致使即便是两个很相近的行记录，极大可能也会被分配到不一样的桶（磁盘块）中。

最坏的状况下每查找一条记录，都要进行一次磁盘IO （可怕）。

优势，哈希结构这样key-val 键值对的形式对于精确查找很是敏感，对全值匹配很友好，因此单条记录查询效率很是高，时间复杂度为 1，可是咱们平常业务来讲，最经常使用的仍是范围搜索，因此不哈希结构适合。

记住一点便可：Hash索引适合精确查找，全值匹配，不适合范围查找。

MySQL目前有Memory引擎和NDB引擎支持Hash索引。

面试官考点之为何不使用二叉树做为索引结构？

首先观察一下二叉树结构

二叉树最多有两个子节点，这种结构致使树的高度会很高，增长IO次数，特殊状况下可能化为链表结构，至关于全表扫描，全量磁盘IO。

假设二叉树结构做为索引，理想状况下是一颗彻底二叉树，那么具备n个节点的彻底二叉树深度为log2x+1

（其中x表示不大于n的最大整数）

若是一个数据在二叉树结构的100层，那么为了查找到此数据，须要进行100次磁盘IO。更糟糕状况下，二叉树会退化成链表结构，既，斜二叉树。

相似的平衡二叉树，高度也很高。

面试官考点之为何不使用B-Tree，而是B+Tree？

既然二叉树结构树高度很高，致使查询时磁盘IO增长，那B-Tree 呢？B-Tree能够存储更多的数据，高度更低，为何不选择？而是B+Tree？

B-Tree是多路平衡搜索树，相比二叉树结构，能够极大的优化磁盘IO次数，可是B-Tree每一个节点中不只包含数据的key（索引值），还有data（整行记录），使用B-Tree结构，优势是找到索引就表明找到了数据记录。

既然如此为何不使用B-Tree结构？仍是老问题，磁盘IO数！！！

咱们知道MySQL读取数据是以页为单位（磁盘块），每页（或者说每一个磁盘块）的存储空间是有限的

若是data 很大，将会致使每页存储的索引数量很小

因此数据表存储的数据量很大的时候一样会致使 B-Tree的深度很大，增大查询时的磁盘I/O次数，进而影响查询效率。

再说到B+Tree，B+Tree是对B-Tree 的一种优化结构，使其更适合实现外存储索引结构

一、非叶子节点只存储键值信息(索引信息)

二、全部的数据记录都按照键值大小顺序存放在同一层的叶子节点上

好处：B+Tree的非叶子节点只存储键值信息，那么每一页能存储更多的索引，树的高度被压缩到很低，磁盘IO次数更小，通常状况下2~4次IO，便可查询到想要的记录。

并且由于表数据都是顺序存储在B+Tree结构的叶子节点，因此对于范围查找很友好，效率高！

面试官考点之索引是加速查询，那么是否应该给表尽量创建多的索引列？

虽然索引的优点是加快查询效率，减小磁盘IO次数，可是盲目建立过多索引，大大增长了维护索引的时间成本和空间成本。

首先说一下索引的好处

一、减小IO次数，提升-检索效率

二、下降数据排序成本，能够减小CPU消耗

时间成本

由于索引是有序的快速查找结构，要维护索引的这个快速查找且有序特性，须要不断的进行调整，而调整就须要时间成本。

建立索引和维护索引要耗费时间，当对表中的数据进行增长、删除和修改的时候，索引也要动态地维护，这样就下降了数据的维护速度。

并且这种时间成本随着数据量的增长而增长！

空间成本

其次，每个索引都是一棵B+Tree，保存索引和指向实体表的引用，须要占据空间。

若是创建的是聚簇索引，数据和主键都保存在索引文件中，则须要更大的空间成本。

敬请期待囧囧小白索引二面内容！

更多精彩内容，欢迎关注微信公众号：囧么肥事 （或搜索：jiongmefeishi）

阅读原文：《MySQL面试小抄》索引考点一面总结