2. B+Tree解析
依然如初看一下B+Tree的数据结构。
为了方便对比，将BTree和B+Tree的数据结构放到了一起。
那么可以看到在B+Tree中叶子节点是存放了全量的数据，而非叶子节点只存储了key值。
咦！这不是就很好的解决了BTree带来的问题吗？可以让每个节点存储更多的数据。每个节点存储的数据越多，那么相对的就是树的深度就不会过深。
了解到了B+Tree的数据结构后，我们在来看看在MySQL中关于B+Tree是如何存储的。
从上图很明显就可以看到俩点不同。
第一点：B+Tree所有的数据都存储在叶子节点上。
第二点：B+Tree所有的叶子节点之间是一种链式环结构
那么在这个过程中到底读取了多少条数据呢！
如果说B+Tree读取数据的深度跟B-Tree的深度一样，都是三层，那么同样的道理每个磁盘的大小为16kb。
那在B+Tree中非叶子节点可以存储多少数据呢！一般来说我们每个表都会存在一个主键。
根据三层来计算，第一层跟第二层存储的是key值，也就是主键值。
都知道int类型所占的内存时4Byte（字节），指针的存储就给个6Byte，一共就是10Tybe，那么第一层节点就可以存储16 * 1000 /10 = 1600。
同理第二层每个节点也是可以存储1600个key。
第三层是叶子节点，每个磁盘存储大小同样安装BTree的计算一样，每条数据占1kb。
那么在B+Tree中三层可以存储的数据就是1600 * 1600 * 16 = 40960000
从这点来看B+Tree存储的数据跟BTree存储的数据根本就不是一个级别。
所以可以得出结论：
B+Tree能保证检索的数据量相对BTree是最多的，而且存储的数据量也是最多的
B+Tree选择索引时尽量选择所占内存空间小的类型，比如int类型。
key所占内存越小，在节点中存储的范围就越多。
3.Hash索引
先来创建一个hash索引alter table user add index hash_gender using hash(gender);
存储引擎使用的是innodb。
会发现name的索引类型还是为Btree，在innodb上创建哈希索引，被称之为伪哈希索引，和真正的哈希索引不是一回事的，这点一定要明白。
在Innodb存储引擎中有一个特殊的功能叫做，自适应哈希索引，当索引值被使用的非常频繁时，它会在内存中基于BTree索引之上再创建一个哈希索引，那么就拥有了哈希索引的一些特点，比如快速查找
哈希索引就是基于哈希表实现的，假设对 name 建立了哈希索引，则查找过程如下图所示，哈希表是根据键值对进行访问的数据结构，它让检索的数据经过哈希函数映射到散列表的对应位置，查找效率非常高。
哈希索引存储的是哈希值和行指针，没有存储key值、字段值，但哈希索引多数是在内存完成的，检索数据是非常快的，所以对性能影响不大。
哈希索引不是按照索引值排序的，所以也就无法排序。
哈希索引只支持等值操作，不支持范围查找，在MySQL中只能只用 =、in 、<>
哈希索引在任何时候都不能避免表扫描
哈希索引在遇到大量哈希冲突时，存储引擎必须遍历链表的所有行指针，逐行比较。
4. B+Tree跟BTree区别
经过了特别漫长的计算、画图现在基本对俩者的区别有一定认识了吧！
咔咔在这里进行总结一下。
B+Tree叶子节点上存储的是全量数据(key+data)，而非叶子节点只存储key
B+Tree在同样的深度下存储的数据是远远大于BTree的。
B+Tree每个叶子节点都有指向下一个叶子节点的链接。这样的好处在于，我们可以从任意一个叶子节点开始遍历，获取接下来所有的数据。
5. B+Tree适合做索引的原因
B+Tree树非叶子节点只存储key值，因此相对于BTree节点可以存储更多的数据，每次读入内存的key值就更多，相对来说I/O就降低
B+Tree树查询效率稳定，任何数据的查找都是必须从叶子节点到非叶子节点，所以说每个数据查找的效率几乎都是相同的。
B+Tree树的叶子节点存储的是全量数据，并且是有序的，所以说只需要遍历叶子节点就可以对所有的key进行扫描，在范围查找时效率更高。
以上就是关于Innodb存储引擎为什么使用B+Tree作为索引的解析。
