首先要了解mysql的io过程
前面提到了访问磁盘，那么这里先简单介绍一下磁盘IO和预读，磁盘读取数据靠的是机械运动，每次读取数据花费的时间可以分为寻道时间、旋转延迟、传输时间三个部分，寻道时间指的是磁臂移动到指定磁道所需要的时间，主流磁盘一般在5ms以下；旋转延迟就是我们经常听说的磁盘转速，比如一个磁盘7200转，表示每分钟能转7200次，也就是说1秒钟能转120次，旋转延迟就是1/120/2 = 4.17ms；传输时间指的是从磁盘读出或将数据写入磁盘的时间，一般在零点几毫秒，相对于前两个时间可以忽略不计。那么访问一次磁盘的时间，即一次磁盘IO的时间约等于5+4.17 = 9ms左右，听起来还挺不错的，但要知道一台500 -MIPS（Million Instructions Per Second）的机器每秒可以执行5亿条指令，因为指令依靠的是电的性质，换句话说执行一次IO的时间可以执行约450万条指令，数据库动辄十万百万乃至千万级数据，每次9毫秒的时间，显然是个灾难。下图是计算机硬件延迟的对比图，供大家参考：
考虑到磁盘IO是非常高昂的操作，计算机操作系统做了一些优化，当一次IO时，不光把当前磁盘地址的数据，而是把相邻的数据也都读取到内存缓冲区内，因为局部预读性原理告诉我们，当计算机访问一个地址的数据的时候，与其相邻的数据也会很快被访问到。每一次IO读取的数据我们称之为一页(page)。具体一页有多大数据跟操作系统有关，一般为4k或8k，也就是我们读取一页内的数据时候，实际上才发生了一次IO，这个理论对于索引的数据结构设计非常有帮助。
结论：每个节点的索引key值越多，对于一次IO拿到的有效数据越多。
1. 与二叉树相比
二叉树相比于顺序查找的确减少了查找次数，但是在最坏情况下，二叉树有可能退化为顺序查找。而且就二叉树本身来说，当数据库的数据量特别大时，其层数也将特别大。二叉树的高度一般是log_2^n，B树的高度是log_t^((n+1)/2) + 1，其高度约比B树大lgt倍。n是节点总数，t是树的最小度数。
假如每个盘块可以正好存放一个B树的结点（正好存放2个文件名）。那么一个BTNODE结点就代表一个盘块，而子树指针就是存放另外一个盘块的地址。
下面，咱们来模拟下B树索引查找文件29的过程：
根据根结点指针找到文件目录的根磁盘块1，将其中的信息导入内存。【磁盘IO操作 1次】
此时内存中有两个文件名17、35和三个存储其他磁盘页面地址的数据。根据算法我们发现：17<29<35，因此我们找到指针p2。
根据p2指针，我们定位到磁盘块3，并将其中的信息导入内存。【磁盘IO操作 2次】
此时内存中有两个文件名26，30和三个存储其他磁盘页面地址的数据。根据算法我们发现：26<29<30，因此我们找到指针p2。
根据p2指针，我们定位到磁盘块8，并将其中的信息导入内存。【磁盘IO操作 3次】
此时内存中有两个文件名28，29。根据算法我们查找到文件名29，并定位了该文件内存的磁盘地址。
2. 与B树相比
B树在提高IO性能的同时，并没与解决元素遍历时效率低下的问题，正是为了解决这个问题，B+数应运而生。B+数只需遍历叶子节点即可实现整棵树的遍历，而B树必须使用中序遍历按序扫库，B+树支持范围查询非常方便。这才是数据库选用B+树的主要原因。
另外，最后说一下，并不是说B+树就比B树好，有很多基于频率的搜索是选用B树，越频繁query的结点越往根上走，前提是需要对query做统计，而且要对key做一些变化。
无论是B树还是B+树由于前边几层反复query，因此早已被加载入内存，不会出现读磁盘IO。一般启动的时候，就会主动换入内存。在内存中B+树并没有优势，只有在磁盘中B+树的威力才能显现。