共计 723 个字符，预计需要花费 2 分钟才能阅读完成。
一、B or B+ ?
对于 mongodb 的索引实现，我目前都不太确定是 B + 树，还是 B 树，因为 mongodb 的官网文档中明确阐明应用 B 树实现的：
然而云栖上有人说问过 WiredTiger 的作者确认用的也是 B + 树：
本文并不想八卦谁对谁错，只单纯的剖析 mongodb 实践上，用哪一种数据结构实现索引，更适宜，只代表自己观点，说的不对，欢送斧正
二、B 树与 B + 树各自的优缺点
B+ 是 B 树的进阶型，不同于 B 树的非叶子节点能够存储数据（或者是数据的物理地址），B+ 树中所有的数据都寄存在叶子节点中，因而，查问速度十分稳固，具体比照见我的这篇[博客]。(https://segmentfault.com/a/11…
三、针对 mongodb 这种非 sql 数据库，哪一种数据结构更快？
耗时一上午检索，找到了几种 mongodb 应用 B 树的 ” 强行 ” 解释，我将其归为如下：
既然是非 sql 数据库，就应该好好利用其反对文本 \ 简单数据类型的劣势，通过表构造的设计，保障数据库的使用者，通过单条查问就能拿到数据, 而 B 树的遍历查问效率尽管不如 B + 树，然而因为非叶子节点间接就能拿到并返回数据，因而单条查问速度是快于 B 树的
典型例子见这 2 篇博客 1 | 博客 2
以下是自己观点：
B 树的单条查问的确是会更快，然而以自己所经验的我的项目教训来说，mongodb 的表不会都是单条查问的场景，更多的应用场景还是基于几个属性的遍历，当然这能够通过创立复合索引去放慢查找速度，然而创立多个索引，自身就会极大的升高数据库写的性能，创立多个索引之后读的性能也不会比照 B + 树有更多的劣势。
综上，如果自己作为引擎的开发者，会抉择 B + 树作为实现索引的数据结构，只管这就义了一部分单条查问的性能，然而罕用场景下查问的性能更为牢靠。