MongoDB的索引到底是使⽤B+树还是B树
先上结论，根据官⽹的说法是 B 树
然⽽笔者看到⼀篇，，⾥⾯有⼈如下回答
实际是B+树，这个在2018年元旦北京的MongoDB专场，我问了WiredTiger引擎的作者，他也确认了是B plus Tree。虽然官⽅⽂档写了B树。
现在有些觉得迷惑了，要是有⼈知道，请留⾔告诉我好么。
由于第⼆个观点，相关的佐证很难，姑且还是采⽤官⽹的的说法是⽤ B 树吧。
那么为什么是 B 树？
在上⼀篇⾥笔者分析过
B+ 是在 B 树上改进，它的数据都在叶⼦节点，同时叶⼦节点之间还加了指针形成链表。范围选择只需要到⾸尾，通过链表就能把所有数据取出来了。
⽽ B 树有啥好处呢？因此查询单条数据的时候，B树的查询效率不固定，最好的情况是 O(1)，因为它不
需要再遍历去到叶⼦节点。所以可以认为在做单⼀数据查询的时候，使⽤ B 树平均性能更好。但是，由于 B 树中各节点之间没有指针相邻，因此 B 树做⼀些数据遍历操作不那么适合。
换⾔之 MySQL 之所以选择 B+，那是因为出于范围选择考虑的。那么 MongoDB 选择 B 树，可能是因为单⼀数据查询多，范围查询少。
那为什么 Mongodb 范围查询少呢？是因为 Mysql 是关系型数据库，⽽ Mongodb 是⾮关系型数据。往下看举例
例⼦
mongodb和mysql结合下⽂图⽚和例⼦都出⾃
设计学⽣和班级⼀对多关系的表。关系型数据库逻辑如下
此时要查 cname 为 1 班的班级，不论是 join，还是先查出所有 cid，后再 student 表⾥匹配这 cid 相同的记录，都避免不了从⼀个表中取⼀个数据，去另⼀个表中逐⾏匹配，如果索引结构是 B+ 树，叶⼦节点上是有指针的，能够极⼤的提⾼这种⼀⾏⼀⾏的匹配速度。
那⾮关系型怎么设计？
然后再执⾏两条查询去计算结果，虽然是可以这么设计，但是 MongoDB 并不推荐。发挥⾮关系型数据库的长处应当这么设计：
假设name这列，我们建了索引！寻执⾏⼀次语句，这样就能查询出⾃⼰想要的结果。
db.class.find( { name: '1班' } )
⽽这，就是⼀种单⼀数据查询!毕竟你不需要去逐⾏匹配，不涉及遍历操作，幸运的情况下，有可能⼀次IO就能够得到你想要的结果。
因此，由于关系型数据库和⾮关系型数据的设计⽅式上的不同。导致在关系型数据中，遍历操作⽐较常见，因此采⽤B+树作为索引，⽐较合适。⽽在⾮关系型数据库中，单⼀查询⽐较常见，因此采⽤B树作为索引，⽐较合适。
参考

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。