文章目录
一、MySQL索引到底是什么
二、为什么要使用索引
三、Innodb为什么使用B+Tree而不使用BTree
1. Btree解析
2. B+Tree解析
3.Hash索引
4. B+Tree跟BTree区别
5. B+Tree适合做索引的原因
四、聚簇索引、非聚簇索引区别
五、表中存在多个索引数据是如何存储的
六、索引的几个技术名词
1. 回表
2. 覆盖索引
3. 最左匹配
4. 索引下推
七、索引存储在什么地方
八、总结
————————————————
你是不是对于MySQL索引的知识点一直都像大杂烩，好像什么都知道，如果进行深究的话可能一个也答不上来。
假如你去面试，面试官让你聊一下对索引的理解，然而你对索引的理解仅限于，检索数据就是快，是一种数据结构这个层面，那你就只能回家等通知了。
为了避免这种尴尬的事情发生，咔咔用时两天将索引的内容在自己理解的范围内进行整理，如整理的不全面可以在评论区进行补充和提建议。
一、MySQL索引到底是什么
相信大多数伙伴都买过技术类的书籍，看完没看完不知道，但是目录肯定看的次数最多。
看目录有没有自己目前的痛点，如果有就会根据目录对应的页码用最快的速度翻阅到相应内容位置。
那么在MySQL中同样也是这样的一个道理，MySQL的索引就是存储引擎为了快速找到数据的一种数据结构
同样在MySQL索引中又分了几种类型，分别为B-tree索引、哈希索引、空间索引、全文索引。
下文所有内容均在Innodb的基础上讨论。
二、为什么要使用索引
索引可以加快数据检索速度，这也是使用的索引的最主要原因。
索引本身具有顺序性，在进行范围查询时，获取的数据已经排好了序，从而避免服务器再次排序和建立临时表的问题。
索引的底层实现本身具有顺序性，通过磁盘预读使得在磁盘上对数据的访问大致呈顺序的寻址，也就是将随机的I/O变为顺序I/O。
这几点不理解就暂时先放着，继续看下文即可，会给你一个满意的解释。
任何事物都存在双面性，既然能提供性能的提升，自然在其它方面也会付出额外的代价。
索引是跟数据共存，因此会占用额外的存储空间。
索引创建和维护需要时间成本，这个成本随着数据量的增大而增大。
索引创建会降低数据的增、删、改的性能，因为在修改数据的同时还需要修改索引数据。
三、Innodb为什么使用B+Tree而不使用BTree
聊到这个问题那就必须得分清楚BTree、B+tree的区别，首先来看一下BTree
1. Btree解析
先来看一下BTree的数据结构是怎么样的，这里咔咔给提供一个网站地址https://www.cs.usfca.edu/~galles/visualization/Algorithms.html，可以看到关于数据结构的一些实现过程。
先来看BTree的数据结构，下图是咔咔已经将数据填充进去的。
这里有一个陌生区关于Max. Degree，这个你可以理解为阶，也可以理解为度。
例如现在这个值设置的是4，那么在一个节点中最多就可以存储三条数据，设置为5那就可以最多放4条记录。
现在可以看到目前只插入了三条数据。
那么再加一条数据，节点就会进行分裂，这个也就验证了当阶设置为n时，一个节点可存n-1条数据。
那接着再来插入几条数据看看。
想要达到快速检索数据，那就需要满足俩个特性，一个是有序，另一个就是平衡。
从下图中可以看到BTree是有一定的顺序性的，平衡性更满足，可以看上文中生成的第一张图。
那么在BTree中找一个值是怎么找呢！
例如现在要找一个值9，看一下寻找过程。
首先看到的数据是4，9是大于4的，所以会往4的右节点寻找。
继续找到范围在6到8的节点，9又大于8，所以还需要往右节点寻找。
最有一步就找到了数据9，这个过程就是BTree数据结构查找数据的执行过程。
了解到了BTree的数据结构后，我们在来看看在MySQL中关于BTree是如何存储的。
在下图中P代表的是指针，指向的是下一个磁盘块。
在第一个节点中的16、24就是代表我们的key值是什么。
date就是这个key值对应的这一行记录是什么。
那么此时想要寻找key为33的这条记录应该怎么找。
33在16和34中间，所以会去磁盘3进行寻找。
在磁盘3中进行判断，指针指向磁盘8。
在磁盘8中即可获取到数据33，然后将data返回。
那么在这个过程中到底读取了多少条数据呢！
在计算之前需要先了解一些知识点。
从MySQL5.7开始，存储引擎默认为innodb，并且innodb存储引擎用于管理数据的最小磁盘单位就是页。
这个页的类型也分为好几种，分别为数据页，Undo页，系统页，事物数据页。
一般说到的页都是数据页。默认的页面大小为16kb，每个页中至少存储2条或以上的行记录。
那么根据BTree数据查找的过程中可以得知一共读取了三个磁盘，那么每个磁盘的大小就是16kb。
而目前的给的案例寻找了三层，那么三层存储的数据就是16kb * 16kb * 16kb = 4096kb。
如果按照一条记录所需内存1kb，那么这三层的BTree就可以存储4096条记录。
各位数据库的数据少则几百万，多则几千万数据，那么BTree的层级就会越来越深，相对的查询效率也会越来越慢。
这个时候是不是应该思考一个问题，那就是为什么在Btree中48kb的内存怎么就只能存储4000多条记录
问题就出现在data上，要知道在计算数据大小时指针地址和key的内存都是没有计算在内的，单单就计算了data的内存。
因为在BTree结构中，节点中不仅存储的有key、指针地址还有对应的数据，所以就会造成单个磁盘存储的数据相对很少的原因。
为了解决单个节点存储数据量小的问题，于是就演变出另一种结构，也就是下文提到了B+Tree
