B-树和B+树最重要的一个区别就是B+树只有叶节点存放数据，其余节点用来索引，而B-树是每个索引节点都会有Data域。

B+树

B+树是为磁盘及其他存储辅助设备而设计一种平衡查找树（不是二叉树）。B+树中，所有记录的节点按大小顺序存放在同一层的叶节点中，各叶节点用指针进行连接。

数据库中B+树索引分为聚集索引（clustered index）和非聚集索引（secondary index）.这两种索引的共同点是内部都是B+树，高度都是平衡的，叶节点存放着所有数据。不同点是叶节点是否存放着一整行数据。

B+树有如下特点:

B+树每个节点可以包含更多的节点，这样做有两个原因,一个是降低树的高度。另外一个是将数据范围变为多个区间，区间越多，数据检索越快。
每个节点不再只是存储一个key了，可以存储多个key。
非叶子节点存储key，叶子节点存储key和数据。
叶子节点两两指针相互链接，顺序查询性能更高。

通俗的讲

B+树的非叶子节点只是存储key，占用空间非常小，因此每一层的节点能索引到的数据范围更加的广。换句话说，每次IO操作可以搜索更多的数据。
叶子节点两两相连，符合磁盘的预读特性。比如叶子节点存储50和55，它有个指针指向了60和62这个叶子节点，那么当我们从磁盘读取50和55对应的数据的时候，由于磁盘的预读特性，会顺便把60和62对应的数据读取出来。这个时候属于顺序读取，而不是磁盘寻道了，加快了速度。
支持范围查询，而且部分范围查询非常高效，每个节点能索引的范围更大更精确,也意味着 B+树单次磁盘IO的信息量大于B-树,I/O效率更高。

原因是数据都是存储在叶子节点这一层，并且有指针指向其他叶子节点，这样范围查询只需要遍历叶子节点这一层，无需整棵树遍历。

局部性原理与磁盘预读

由于磁盘的存取速度与内存之间鸿沟,为了提高效率,要尽量减少磁盘I/O.磁盘往往不是严格按需读取，而是每次都会预读,磁盘读取完需要的数据,会顺序向后读一定长度的数据放入内存。而这样做的理论依据是计算机科学中著名的局部性原理：

当一个数据被用到时，其附近的数据也通常会马上被使用，程序运行期间所需要的数据通常比较集中

B-树

B-树,这里的 B 表示 balance( 平衡的意思),B-树是一种多路自平衡的搜索树
它类似普通的平衡二叉树，不同的一点是B-树允许每个节点有更多的子节点。

B-树有如下特点

所有键值分布在整颗树中。
任何一个关键字出现且只出现在一个结点中。
搜索有可能在非叶子结点结束。
在关键字全集内做一次查找,性能逼近二分查找。

B-树和B+树的区别

B+树内节点不存储数据，所有数据存储在叶节点导致查询时间复杂度固定为 log n。
B-树查询时间复杂度不固定，与 key 在树中的位置有关，最好为O(1)。
B+树叶节点两两相连可大大增加区间访问性，可使用在范围查询等。
B-树每个节点 key 和 data 在一起，则无法区间查找。
B+树更适合外部存储(存储磁盘数据)。由于内节点无 data 域，每个节点能索引的范围更大更精确。

MongoDB 为什么使用B-树?

B+树内节点不存储数据，所有 data 存储在叶节点导致查询时间复杂度固定为 log n。而B-树查询时间复杂度不固定，与 key 在树中的位置有关，最好为O(1)

我们说过，尽可能少的磁盘 IO 是提高性能的有效手段。MongoDB 是聚合型数据库，而 B-树恰好 key 和 data 域聚合在一起。

至于MongoDB为什么使用B-树而不是B+树，可以从它的设计角度来考虑，它并不是传统的关系性数据库，而是以Json格式作为存储的nosql，目的就是高性能，高可用，易扩展。首先它摆脱了关系模型，上面所述的优点2需求就没那么强烈了，其次Mysql由于使用B+树，数据都在叶节点上，每次查询都需要访问到叶节点，而MongoDB使用B-树，所有节点都有Data域，只要找到指定索引就可以进行访问，无疑单次查询平均快于Mysql。

哈希索引

简单地说，哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。

B+树索引和哈希索引的区别

如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据。
如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索。
同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）。
哈希索引也不支持多列联合索引的最左匹配规则。
B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。
解决Hash碰撞冲突方法总结 https://blog.csdn.net/zeb_perfect/article/details/52574915

备注：以上内容均摘抄自网络，并非原创，仅供个人学习交流使用，望各路大牛，发现不对的地方，不吝赐教，留言即可。

Mysql InnoDB B+树索引和哈希索引的区别？ MongoDB 为什么使用B-树?相关推荐

MySQL B+树索引和哈希索引的区别
导读在MySQL里常用的索引数据结构有B+树索引和哈希索引两种,我们来看下这两种索引数据结构的区别及其不同的应用建议. 二者区别备注:先说下,在MySQL文档里,实际上是把B+树索引写成了BTRE ...
MySQL 索引：哈希索引、B+树索引、最左前缀匹配规则、全文索引
文章目录索引什么是索引索引优缺点与适用场景常见的索引哈希索引自适应哈希索引 B+树索引聚集索引非聚集索引使用方法联合索引最左前缀匹配规则覆盖索引全文索引使用方法索引什么 ...
MySQL 索引：哈希索引、B+树索引、全文索引
文章目录索引引言常见的索引哈希索引自适应哈希索引 B+树索引聚集索引非聚集索引使用方法联合索引最左前缀匹配规则覆盖索引全文索引使用方法索引引言为什么需要索引? 倘若不使 ...
MySQL B+树索引和哈希索引介绍
* GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源. 索引介绍索引是一种特殊的数据库结构,被设计用来快速查询数据库表中的特定记录.索引有多种类型,就像字典有拼音查找和偏旁 ...
MySQL索引（B+Tree 索引、哈希索引、全文索引、空间数据索引）、索引优化、优点、使用场景
1. MySQL 索引是在存储引擎层实现的,而不是在服务器层实现的,所以不同存储引擎具有不同的索引类型和实现. 1.1 B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型. 因为不再需要 ...
B+树索引和哈希索引
转自:https://www.cnblogs.com/zengkefu/p/5647279.html 导读在MySQL里常用的索引数据结构有B+树索引和哈希索引两种,我们来看下这两种索引数据结构的区 ...
B+树索引和哈希索引的区别——我在想全文搜索引擎为啥不用hash索引而非得使用B+呢？...
哈希文件也称为散列文件,是利用哈希存储方式组织的文件,亦称为直接存取文件.它类似于哈希表,即根据文件中关键字的特点,设计一个哈希函数和处理冲突的方法,将记录哈希到存储设备上. 在哈希文件中,是使用一个 ...
MySQL InnoDB存储引擎聚集和非聚集索引
B+树索引索引的目的在于提高查询效率,可以类比字典,如果要查"mysql"这个单词,我们肯定需要定位到m字母,然后从下往下找到y字母,再找到剩下的sql.如果没有索引,那么你可能 ...
数据库中的索引技术——哈希索引
1.哈希索引哈希索引(hash index)基于哈希表实现,只有精确匹配索引所有列的查询才有效.对于每一行数据,存储引擎都会对所有的索引列计算一个哈希码(hash code),哈希码是一个较小的值, ...

Mysql InnoDB B+树索引和哈希索引的区别？ MongoDB 为什么使用B-树?

B+树