《MySQL 面试小抄》索引考点一面总结
我是肥哥，一名不业余的面试官！
我是囧囧，一名踊跃找工作的小菜鸟，囧囧示意：面试最怕的就是面试官问的知识点太抽象，本人无奈疾速定位到关键问题点！！！
本期次要面试考点
面试官考点之谈谈你对索引的了解？面试官考点之解释一下计算机层面索引快的起因？面试官考点之为什么不应用哈希构造作为索引构造？面试官考点之为什么不应用二叉树作为索引构造？面试官考点之为什么不应用 B -Tree，而是 B +Tree？面试官考点之索引是减速查问，那么是否应该给表尽可能建设多的索引列？
面试官考点之谈谈你对索引的了解？
谈到索引，最先联想到的大略就是字典目录，依据 MySQL 官网定义，索引是用来帮忙 MySQL高效获取数据 的一种数据结构。
实质上：索引是一种有序的疾速查找的数据结构，用来疾速高效的查找数据。
简略来说，能够类比字典目录，火车车次表。
面试官考点之解释一下计算机层面索引快的起因？
计算机从磁盘获取数据，加载到内存期间，个别都要经验 3 个惯例的 耗时过程：
1、寻道（工夫）：确定要读的数据在哪个磁道消耗的工夫
2、旋转提早（工夫）：确定要读的数据在磁道上的哪个扇区消耗的工夫
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 的一种优化结构，使其更适宜实现外存储索引构造
1、非叶子节点只存储键值信息(索引信息)
2、所有的数据记录都依照键值大小程序寄存在同一层的叶子节点上
益处：B+Tree 的非叶子节点只存储键值信息，那么每一页能存储更多的索引，树的高度被压缩到很低，磁盘 IO 次数更小，个别状况下 2~4 次 IO，即可查问到想要的记录。
而且因为表数据都是顺序存储在 B +Tree 构造的叶子节点，所以对于 范畴查找很敌对，效率高！
面试官考点之索引是减速查问，那么是否应该给表尽可能建设多的索引列？
尽管索引的劣势是放慢查问效率，缩小磁盘 IO 次数，然而自觉创立过多索引，大大增加了保护索引的工夫老本和空间老本。
首先说一下索引的益处
1、缩小 IO 次数，进步 - 检索效率
2、升高数据排序老本，能够缩小 CPU 耗费工夫老本
因为索引是有序的疾速查找构造，要保护索引的这个疾速查找且有序个性，须要一直的进行调整，而调整就须要工夫老本。
创立索引和保护索引要消耗工夫，当对表中的数据进行减少、删除和批改的时候，索引也要动静地保护，这样就升高了数据的保护速度。
而且这种工夫老本随着数据量的减少而减少！
空间老本
其次，每一个索引都是一棵 B +Tree，保留索引和指向实体表的援用，须要占据空间。
如果建设的是 聚簇索引，数据和主键都保留在索引文件 中，则须要更大的空间老本。
敬请期待囧囧小白索引二面内容！
更多精彩内容，欢送关注 微信公众号：囧么肥事（或搜寻：jiongmefeishi）
浏览原文：《MySQL 面试小抄》索引考点一面总结