索引的底层数据结构

索引的底层数据结构有：
1 树Tree，准确的说是B+树
2 Hash

时间复杂度对比：
Hash的时间O(1)
Tree的O(logn)

为什么索引采用B+树，而不采用Hash这种结构？
Hash这种结构对与获取单条记录时的查询效率是要比B+树效率要高的，
但是对与数据的范围查找效率就很低，特别是对于数据量大的时候（10万 甚至百万级别的数据），
为什么低？它是根据字段值算出获取一个hash值，然后根据hash值找到在索引表中查找出hash值对应的数据行，它的索引没有按顺序存储

B+树:是一种多路平衡树，一个横向存放多个节点，并且它的非叶子节点都只存放指向子节点的索引指针，不存放数据。所有
非叶子节点都存放一个节点在叶子节点上，并且这个叶子节点是一个有序的列表结构。

当我们查一个范围数据时，通过B+树搜索

多路：一课树每个节点最多可以拥有大于2个子节点的树

平衡树： 一颗树左子树和右子树保持相对平衡，不会出现一边层级特别多，一边层级特别少的情况

为什么不用二叉树？
二叉树为非平衡树，如果是有序递变的数据，很有可能就会变成左边树层级过高，或则右边树的层级过高，甚至是退化成链表。

层级过高为什么就不能用了呢？
假设是1,2,3,4,5,6这样的数据，如果我们要找到底部6这个数据，就要进行6次IO（加载磁盘数据进内存，索引是在磁盘文件中以表的形式存在的）才能找到。如果按一次IO10ms计算，60ms也不算什么。但是假设是100万呢？1001000010ms，也就是10000s，换算成分钟也就是167，所以这种结构肯定是不行的。

为什么不用红黑二叉树？
红黑二叉树一种平衡树，虽然它不会出现有一树的层级过高的情况，但是它还是没有从根本上解决树的层级问题，随着数据量增大，树的层级会越来越高。要遍历叶子节点的数据IO消耗还是过高。

为什么没有采用B树，或则说B-树？
B树虽然虽然通过多路平衡树解决了树的高度问题，但是它对与访问数据的查找效率还是低下的，对于数据访问在非叶子节点和叶子节点都有的范围，它不仅非叶子节点的遍历还需要做叶子节点的遍历。