实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在2~4层。MySQL的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1~3次磁盘I/O操作。

三：下面说下mysql中innodb引擎中聚簇表和myisam中非聚簇表的遍历数据的不同

如下图（来自网络）：

看上去聚簇索引的效率明显要低于非聚簇索引，因为每次使用辅助索引检索都要经过两次B+树查找，这不是多此一举吗？聚簇索引的优势在哪？

1 由于行数据和叶子节点存储在一起，这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。

2 辅助索引使用主键作为"指针" 而不是使用行地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"，使用聚簇索引可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。

四：最后说下mysql中的B+tree索引的好处和限制（摘自高性能mysql第三版）

（一）可以使用的情况：

可以使用btree索引的查询类型，btree索引使用用于全键值、键值范围、或者键前缀查找，其中键前缀查找只适合用于根据最左前缀的查找。前面示例中创建的多列索引对如下类型的查询有效：

1）全值匹配

全值匹配指的是和索引中的所有列进行匹配，即可用于查找姓名和出生日期

2）匹配最左前缀

如：只查找姓，即只使用索引的第一列

3）匹配列前缀

也可以只匹配某一列值的开头部分，如：匹配以J开头的姓的人（like 'J%')，这里也只是使用了索引的第一列，且是第一列的一部分

4）匹配范围值

如查找姓在allen和barrymore之间的人，这里也只使用了索引的第一列

5）精确匹配某一列并范围匹配另外一列

如查找所有姓为allen，并且名字字母是K开头的，即，第一列last_name精确匹配，第二列first_name范围匹配

6）只访问索引的查询

btree通常可以支持只访问索引的查询，即查询只需要访问索引，而无需访问数据行，即，这个就是覆盖索引的概念。需要访问的数据直接从索引中取得，这个是针对innodb中btree索引而言的。

因为索引树中的节点是有序的，所以除了按值查找之外，索引还可以用于查询中的order by操作，一般来说，如果btree可以按照某种方式查找的值，那么也可以按照这种方式用于排序，所以，如果order by子句满足前面列出的几种查询类型，则这个索引也可以满足对应的排序需求。

(二）下面是关于btree索引的限制：

1）如果不是按照索引的最左???开始查找的，则无法使用索引(注意，这里不是指的where条件的顺序，即where条件中，不管条件顺序如何，只要where中出现的列在多列索引中能够从最左开始连贯起来就能使用到多列索引)

2）不能跳过索引中的列，如创建了多列索引（姓，名，出生日期）：查询条件为姓和出生日期，跳过了名字列，这样，多列索引就只能使用到姓这一列。

3）如果查询中有某个列的范围查询，则其右边所有列都无法使用索引优化查询，如：where last_name=xxx and first_name like ‘xxx%’ and dob=’xxx’;这样，first_name列可以使用索引，这列之后的dob列无法使用索引。

总结：mysql中常用的引擎有innodb和myisam,这两个引擎中创建的默认索引都是B-tree索引，而都是B+tree结构实现的，并且innodb和myisam具体叶子节点存储的内容有所不同，然后覆盖索引是针对innodb引擎的索引而言的，因为myisam引擎中b-tree索引的叶子节点存储的仅仅是行指针。