学习笔记--mysql索引底层数据结构

        此篇仅作为自己平时的一个学习总结，学习的方式也是通过学习其他博主的文章得来，所以肯定没那么深入，如果你觉得有用，也可以收藏阅读，我会持续加油学习，越来越深入下去的；

        这次的主题是mysql数据库，mysql从数据储存的结构上，有很多种，每一个有他的优势和劣势；那提到mysql优化，就一定会提到索引结构，不了解索引的结构去学习mysql，肯定是不行的，于是自己下定决心开始总结索引的一切相关，首先先从索引的数据结构开始，那么都有哪些呢？

        1.  二叉树 ，顾名思义，就是一个节点会有两个分支，左边是储存相对更小的数据，右边是储存相对更大的数据，如图手绘了一个非常简单的二叉树；那么二叉树是怎么做到储存数据的呢，答案就在节点上，每一个节点上都会以key-value的形式进行储存，key是索引字段的值，value是索引所在行的磁盘文件地址；

        

2.  红黑树，一开始接触到红黑树的我很好奇，怎么数据结构会有红色和黑色这么个东西呢？后来发现完全不是颜色的问题，红黑树也可以理解为自动平衡二叉树，是二叉树的优化，为什么会有这样的优化呢？因为当二叉树储存数据的时候有一个明显的弊端，比如看下图；

        当二叉树刚好储存一串连续的数据之后，就会按照右边大的规则，一直朝着一个方向就会拓展，假如这个时候查找数据的话，又刚好不幸想要查找的数据就在最底层，那就要经过很多次的查询才能查到数据，就会非常的消耗性能，等待时间也是非常长；所以索引结构的优化应运而生，而平衡二叉树也就是红黑树刚好就是在解决这个问题，当有新的数据插入进来以后，如果左右两边是不平衡的，二叉树就会自动变换最高的节点，比如最开始的节点是1，随着数据的插入连续插入了 1 2 3 4，那么就会将2作为顶节点，保证两边的高度差不超过1，就像这样：

        

        这样在查找数据的时候就会从原来的要经过4次查询，变化成3次查询啦；

所以在此处也引出查询速度的关键，就是在于储存数据的结构的高度是多少，高度越高查询的性能就会越慢，所以优化的核心就是在于，如何在储存海量数据的前提之下，还可以尽量减少树的高度，减少查找次数；

        当初我以为索引的数据优化到这也就结束了，但是其实还远远不止于此，因为倘若索引数据结构就是用红黑树的话，还会存在新的问题，比如如果就是自己玩一下，储存数据量少的情况之下，当然没什么问题；但是像企业级别的千万级别的储存，这个结构明显问题很大，前面也说了，查询的性能很大程度取决于树的高度，那大家做一个假设，一千万条数据用红黑树的方式储存，高度是多少？

        害，别算了，反正很高就对了，查询一个数据可能几十秒都不止，那就会有新的数据结构的优化，那就是B树和B+树；

        3.   B树，也叫做B-树，（所以B树种类不是三种哈，是两种，回想起以前别人问我，讲讲B树的理解，我一上来就说B树有三种，B，B-和B+树，真的挺2B的）；

        

那对比红黑树，又做了哪些优化呢？联系刚提过的树的高度对查询性能的影响，优化的最明显的地方就是树的高度，B树先从磁盘中用相对更大的空间用于储存索引文件和Data文件，这样树的高度就是急剧降低，一个节点空间大概是在16KB左右，可以储存大概16个索引和Data文件；

        B树结构有几个特点：

            3.1.叶节点具有相同的深度，叶节点的指针为空

            3.2.所有的索引元素不重复

            3.3.节点的索引数据从左到右递增

在这样的结构下，海量数据结构会被优化，高度也会减少，看到这个时候我已经以为索引的最后结构就是B树了，然而最终的Boss并不是B树，而是接下来要提到的继续优化的B+树，此时此刻深深感受到，搞技术永无止境啊，也许N年之后又会被优化成什么牛逼的结构，也期待自己能见证甚至参与某一项技术的变革升级；

        害，扯多了，回正题；

        4.    B+树，也就是优化后的B树结构是怎么样的，有哪些优势呢？看图

和B树相比，优化的方面有：

            4.1.树的高度再次被优化降低，可以做到千万级别数据树的高度控制在4以内；

            4.2.区间访问的速度会更快，性能更好；

那么导致这样优化的原因是因为数据结构的哪里的升级呢？

            4.3.非叶子节点不储存data，只储存索引或冗余索引，这样就可以放更多的索引，刚刚也提到过，在一个节点大概是16KB左右的大小，以B树的结构大概是可以放16个左右的索引，因为是携带着data的，所以基本上就这么个范围了，不可能再多了；但是B+树，牛就牛在非叶子节点不储存data，因为索引占的空间大小最多也就几B，data文件大小在1K左右，要知道1KB=1024B啊；B+树将data优化到了子节点，这样非叶子节点就可以从原来的只能储存十几个索引，变成可以储存大概1000多个索引，这是100倍左右的优化啊，就算是千万级别的索引数据，也可以只需要3层最多4层储存完毕，就算数据在最底层，也只需要三次或者四次索引就可以找到；当然，假如数据真的突破千万，还是建议分库分表会好一点；

            4.4.叶子节点包含所有索引字段，并且叶子节点用指针相连，提高区间访问的性能；这一点的优化主要针对什么呢？我觉得是范围查找，我们都知道，hashmap的结构是以key-value的形式存在的，一个key对应一个value，查询速度也是相当的快，甚至有时候快过B+树，那么为什么索引结构用的不是hashmap而是B+呢？其中，次要原因，有哈希冲突，但是主要的原因还是在范围查找的这一块，hashmap的key-value查找是通过hashcode方式和equals来查找的，假如需要范围查找而且恰好范围又太大的时候，hashmap一个一个查，什么时候是个头啊；而相比之下B+树的这个结构特点就很好的解决了这个问题，就是叶子节点会有指针连接，数据会按照顺序依次排列，这样在范围查找过程中数据就会依次快速查找下去，性能相比hashmap更胜一筹；

        所以结合以上，B+树解决了数据量大的情况下，树的高度降低到最低的问题，也解决了范围查找性能提升的问题；也是最终索引的结构，明白了这一点，当以后数据表进行优化的时候，就会有一个基本的思路，经常涉及到查询需求的而且是全表唯一最好递增的字段，最好设计成索引字段；

最后附上学习数据结构的一个网站，是国外一个大神制作的网站，全英的，不过英文阅读难度也还好；link送上，建议收藏；

https://myusf.usfca.edu/

实在不行谷歌浏览器翻译🐴，我继续肝数据结构与算法了，下次再见~