面试题：MySQL索引为何用B+树？

前言

讲到索引，第一反应确定是能提升查询效率。例如书的目录，想要查找某一章节，会先从目录中定位。若是没有目录，那么就须要将全部内容都看一遍才能找到。

索引的设计对程序的性能相当重要，若索引太少，对查询性能受影响；而若是索引太多，则会影响增/改/删等的性能。

知识点

MySQL中通常支持如下几种常见的索引：

• B+树索引
• 全文索引
• 哈希索引

咱们今天重点来说下B+树索引，以及为何要用B+树来做为索引的数据结构。

B+树索引并不能直接找到具体的行，只是找到被查找行所在的页，而后DB经过把整页读入内存，再在内存中查找。

重温数据结构

1.1 哈希结构

若有 三、一、二、十、九、0、四、6这8个数据，创建如图1-1所示哈希索引。

• 直接查询：如今要从8个数中查找6这条记录，只须要计算6的哈希值，即可快速定位记录，时间复杂度为O(1)。

• 范围查询：若是要进行范围查询（大于4的数据），那这个索引就彻底没用了。

图1-1 哈希索引

1.2 二叉树查找树

二叉树是一种经典的数据结构，要求左子树小于根节点，右子树大于根节点。

若有 三、一、二、十、九、0、四、6这8个数据，创建如图1-2所示二分查找树。

• 直接查询：假设查找键值为6的记录，先找到根4，4<6，所以查找4的右子树，找到9；9大于6，所以查找9的左子树；一共查找3次。但若是顺序查找，则须要查找8次（位于最后）。

• 范围查询：若是须要查找大于4的数据，则遍历4的右子树就好了。

图1-2 二叉查找树

1.3 平衡二叉树（AVL树）

按照二叉查找树的定义，它是能够任意的构造，一样是这些数字，能够按照图1-3-1的方式来创建二叉查找树。一样查找数据6，须要查找5次。

图1-3-1 性能较差的二叉查找树

所以为了最大性能地构造一个二叉查找树，须要它是平衡的，即平衡二叉树。

平衡二叉树定义：首先符合二叉查找树的定义，另外任何节点的两个子树高度最大差为1。

平衡二叉树的查询速度是很快的，可是有缺点：

1. 维护树的代价是很是大，在进行插入或更新时，常常会须要屡次左旋或右旋来维持平衡。如图1-3-2所示
2. 数据量多的时候，树会很高，须要屡次I/O操做。
3. 在进行范围查找时，假设查找>=3，先找到3，而后须要查找到3的父节点，而后遍历父节点的右子树。

图1-3-2 平衡二叉树AVL

1.4 B+ 树

在B+树中，全部记录节点存放在叶子节点上，且是顺序存放，由各叶子节点指针进行链接。若是从最左边的叶子节点开始顺序遍历，能获得全部键值的顺序排序。

若有 三、一、二、十、九、0、四、6这8个数据，可创建如图1-4-1所示高度为2的B+树。

图1-4-1 高度为2的B+树

在进行更新时，B+树一样须要相似二叉树的旋转操做。举例，假设新增一个7，那能够直接填充到四、6的后面。若是再添加8，那么就须要进行旋转了，感觉下面的B+树旋转过程。

图1-4-2 高度为3的B+树

采用B+树的索引结构优势：

1. B+树的高度通常为2-4层，因此查找记录时最多只须要2-4次IO，相对二叉平衡树已经大大下降了。
2. 范围查找时，能经过叶子节点的指针获取数据。例如查找大于等于3的数据，当在叶子节点中查到3时，经过3的尾指针便能获取全部数据，而不须要再像二叉树同样再获取到3的父节点。

未完待续…

若是想要实时关注更新的文章以及分享的干货，能够关注个人公众号