二叉查找树
二叉树具有以下性质：左子树的键值小于根的键值，右子树的键值大于根的键值。
如下图所示就是一棵二叉查找树，
对该二叉树的节点进行查找发现深度为1的节点的查找次数为1，深度为2的查找次数为2，深度为n的节点的查找次数为n，因此其平均查找次数为 (1+2+2+3+3+3) / 6 = 2.3次
二叉查找树可以任意地构造，同样是2,3,5,6,7,8这六个数字，也可以按照下图的方式来构造：
但是这棵二叉树的查询效率就低了。因此若想二叉树的查询效率尽可能高，需要这棵二叉树是平衡的，从而引出新的定义——平衡二叉树，或称AVL树。
平衡二叉树（AVL Tree）
平衡二叉树（AVL树）在符合二叉查找树的条件下，还满足任何节点的两个子树的高度最大差为1。下面的两张图片，左边是AVL树，它的任何节点的两个子树的高度差<=1；右边的不是AVL树，其根节点的左子树高度为3，而右子树高度为1；
如果在AVL树中进行插入或删除节点，可能导致AVL树失去平衡，这种失去平衡的二叉树可以概括为四种姿态：LL（左左）、LR（左右）、RL（右左）、RR（右右）。它们的示意图如下：
这四种失去平衡的姿态都有各自的定义：
LL：LeftLeft，也称“左左”。插入或删除一个节点后，根节点的左孩子（Left Child）的左孩子（Left Child）还有非空节点，导致根节点的左子树高度比右子树高度高2，AVL树失去平衡。
RR：RightRight，也称“右右”。插入或删除一个节点后，根节点的右孩子（Right Child）的右孩子（Right Child）还有非空节点，导致根节点的右子树高度比左子树高度高2，AVL树失去平衡。
LR：LeftRight，也称“左右”。插入或删除一个节点后，根节点的左孩子（Left Child）的右孩子（Right Child）还有非空节点，导致根节点的左子树高度比右子树高度高2，AVL树失去平衡。
RL：RightLeft，也称“右左”。插入或删除一个节点后，根节点的右孩子（Right Child）的左孩子（Left Child）还有非空节点，导致根节点的右子树高度比左子树高度高2，AVL树失去平衡。
AVL树失去平衡之后，可以通过旋转使其恢复平衡。下面分别介绍四种失去平衡的情况下对应的旋转方法。
LL的旋转。LL失去平衡的情况下，可以通过一次旋转让AVL树恢复平衡。步骤如下：
1. 将根节点的左孩子作为新根节点。
2. 将新根节点的右孩子作为原根节点的左孩子。
3. 将原根节点作为新根节点的右孩子。
LL旋转示意图如下： 
RR的旋转：RR失去平衡的情况下，旋转方法与LL旋转对称，步骤如下：
1. 将根节点的右孩子作为新根节点。
2. 将新根节点的左孩子作为原根节点的右孩子。
3. 将原根节点作为新根节点的左孩子。
RR旋转示意图如下： 
LR的旋转：LR失去平衡的情况下，需要进行两次旋转，步骤如下：
1. 围绕根节点的左孩子进行RR旋转。
2. 围绕根节点进行LL旋转。
LR的旋转示意图如下： 
RL的旋转：RL失去平衡的情况下也需要进行两次旋转，旋转方法与LR旋转对称，步骤如下：
1. 围绕根节点的右孩子进行LL旋转。
2. 围绕根节点进行RR旋转。
RL的旋转示意图如下： 
BTree特性
InnoDB存储引擎中默认每个页的大小为16KB，InnoDB在把磁盘数据读入到磁盘时会以页为基本单位，B-Tree结构的数据可以让系统高效的找到数据所在的磁盘块。为了描述B-Tree，首先定义一条记录为一个二元组[key, data] ，key为记录的键值，对应表中的主键值，data为一行记录中除主键外的数据。对于不同的记录，key值互不相同。
一个 m 阶的B树满足以下条件：
1. 每个结点至多拥有m棵子树；
2. 根结点至少拥有两颗子树（存在子树的情况下）；
3. 除了根结点以外，其余每个分支结点至少拥有 m/2 棵子树；
4. 所有的叶结点都在同一层上，到达任何一个叶结点最短路径的长度都是相同的；
5. 有 n 棵子树的分支结点则存在 n-1 个关键字，关键字按照递增次序进行排列；
6. 每个非终端节点包含n个关键字信息（P0,P1,…Pn, k1,…kn）
7. 关键字数量需要满足ceil(m/2)-1 <= n <= m-1；
8. ki(i=1,…n)为关键字，且关键字升序排序。
9. Pi(i=1,…n)为指向子树根节点的指针。P(i-1)指向的子树的所有节点关键字均小于ki，但都大于k(i-1)
模拟查找关键字29的过程：
1. 根据根节点找到磁盘块1，读入内存。【磁盘I/O操作第1次】
2. 比较关键字29在区间（17,35），找到磁盘块1的指针P2。
3. 根据P2指针找到磁盘块3，读入内存。【磁盘I/O操作第2次】
4. 比较关键字29在区间（26,30），找到磁盘块3的指针P2。
5. 根据P2指针找到磁盘块8，读入内存。【磁盘I/O操作第3次】
6. 在磁盘块8中的关键字列表中找到关键字29。
分析上面过程，发现需要3次磁盘I/O操作，和3次内存查找操作。由于内存中的关键字是一个有序表结构，可以利用二分法查找提高效率。而3次磁盘I/O操作是影响整个B-Tree查找效率的决定因素。B-Tree相对于AVLTree缩减了节点个数，使每次磁盘I/O取到内存的数据都发挥了作用，从而提高了查询效率。
B树上大部分的操作（插入、删除、查询）所需要的磁盘存取次数和B树的高度是成正比的，并且B树是尽量多的在节点上存储信息，保证导数尽量少，在B树中可以检查多个子结点，由于在一棵树中检查任意一个结点都需要一次磁盘访问，所以B树避免了大量的磁盘访问，减少了磁盘I/O。
BTree操作过程
插入
新结点一般插在第h层，通过搜索找到对应的结点进行插入，那么根据即将插入的结点的数量又分为下面几种情况。
1. 如果该结点的关键字个数没有到达m-1个，那么直接插入即可；
2. 如果该结点的关键字个数已经到达了m-1个，那么根据B树的性质显然无法满足，需要将其进行分裂。分裂的规则是该结点分成两半，将中间的关键字进行提升，加入到父亲结点中，但是这又可能存在父亲结点也满员的情况，则不得不向上进行回溯，甚至是要对根结点进行分裂，那么整棵树都加了一层。
其过程如下：
删除
同样的，我们需要先通过搜索找到相应的值，存在则进行删除，需要考虑删除以后的情况，
1. 如果该结点拥有关键字数量仍然满足B树性质，则不做任何处理；
2. 如果该结点在删除关键字以后不满足B树的性质（关键字没有到达ceil(m/2)-1的数量），则需要向兄弟结点借关键字，这有分为兄弟结点的关键字数量是否足够的情况。
1) 如果兄弟结点的关键字足够借给该结点，则过程为将父亲结点的关键字下移，兄弟结点的关键字上移；
2) 如果兄弟结点的关键字在借出去以后也无法满足情况，即之前兄弟结点的关键字的数量为ceil(m/2)-1，借的一方的关键字数量为ceil(m/2)-2的情况，那么我们可以将该结点合并到兄弟结点中，合并之后的子结点数量少了一个，则需要将父亲结点的关键字下放，如果父亲结点不满足性质，则向上回溯；
其余情况参照BST中的删除。
其过程如下：
B+Tree特性
B+Tree是在B-Tree基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用B+Tree实现其索引结构。
从上一节中的B-Tree结构图中可以看到每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。
以一个m阶树为例：
1. 根结点只有一个，分支数量范围为[2，m]；
2. 分支结点，每个结点包含分支数范围为[ceil(m/2), m]；
3. 所有非叶子节点的关键字数目等于它的分支数量，关键字顺序递增【此处有争议：或者等于分支数量-1】；
4. 所有叶子结点都在同一层，且关键字数目范围是[ceil(m/2),m]
5. 所有非叶子节点的关键字可以看成是索引部分，这些索引等于其子树（根结点）中的最大（或最小）关键字【此处有争议】。
例如一个非叶子节点包含信息: (n，A0,K0, A1,K1,……,Kn,An)，其中Ki为关键字，Ai为指向子树根结点的指针，n表示关键字个数。即Ai所指子树中的关键字均小于或等于Ki，而Ai+1所指的关键字均大于Ki（i=1，2，……，n）。
6. 所有叶子节点之间都有一个链指针，指向相邻的后一个叶子结点的指针信息，主要是为了加快检索多个相邻叶子结点的效率考虑。
通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。因此可以对B+Tree进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。
可能上面例子中只有22条数据记录，看不出B+Tree的优点，下面做一个推算：
InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为是估值，为方便计算，这里的K取值为〖10〗^3）。也就是说一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿 条记录。
实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在2~4层。mysql的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1~3次磁盘I/O操作。
其操作和B树的操作是类似的，不过需要注意的是，在增加值的时候，如果存在满员的情况，将选择结点中的值作为新的索引，还有在删除值的时候，索引中的关键字并不会删除，也不会存在父亲结点的关键字下沉的情况，因为那只是索引。
B+Tree操作过程
插入
l 例1：
往下图的3阶B+树中插入关键字9
首先查找9应插入的叶节点(最左下角的那一个),插入发现没有破坏B+树的性质,完毕。插完如下图所示:
l 例2：
往下图的3阶B+树插入20
首先查找20应插入的叶节点(第二个叶子节点),插入，如下图
发现第二个叶子节点已经破坏了B+树的性质,则把之分解成[20 21], [37 44]两个,并把21往父节点移，如下图
发现父节点也破坏了B+树的性质,则把之再分解成[15 21], [44 59]两个,并把21往其父节点移，如下图
这次没有破坏B+树的性质(如果还是不满足B+树的性质,可以递归上去,直到满足为至),插入完毕。
l 例3：
往下图的3阶B+树插入100
首先查找100应插入的叶节点(最后一个节点), 插入，如下图
修改其所有父辈节点的键值为100(只有插入比当前树的最大数大的数时要做此步),如下图
然后重复Eg.2的方法拆分节点,最后得
删除
l 例1：
删除下图3阶B+树的关键字91
首先找到91所在叶节点(最后一个节点),删除之，如下图
没有破坏B+树的性质,删除完毕
l 例2：
删除下图3阶B+树的关键字97
首先找到97所在叶节点(最后一个节点),删除之，然后修改该节点的父辈的键字为91(只有删除树中最大数时要做此步)，如下图
l 例3：
删除下图3阶B+树的关键字51
首先找到51所在节点(第三个节点),删除之，如下图
破坏了B+树的性质,从该节点的兄弟节点(左边或右边)借节点44，并修改相应键值,判断没有破坏B+树,完毕，如下图
l 例4：
删除下图3阶B+树的关键字59
首先找到59所在叶节点(第三个节点),删除之，如下图
破坏B+树性质,尝试借节点,无效(因为左兄弟节点被借也会破坏B+树性质),合并第二第三叶节点并调整键值，如下图
l 例5：
删除下图3阶B+树的关键字63
首先找到63所在叶节点(第四个节点),删除之，如下图
合并第四五叶节点并调整键值，如下图
发现第二层的第二个节点不满足B+树性质,从第二层的第一个节点借59,并调整键值，如下图
完毕
B树和B+树的区别
这都是由于B+树和B具有这不同的存储结构所造成的区别，以一个m阶树为例。
1. 关键字的数量不同；B+树中分支结点有m个关键字，其叶子结点也有m个，其关键字只是起到了一个索引的作用，但是B树虽然也有m个子结点，但是其只拥有m-1个关键字。【注：此处有争议，B+树到底是与B 树n-1个关键字有n棵子树保持一致，还是B+树n个关键字的结点中含有n棵子树；两种定义都可以，只要自己实现的时候统一用一种就行】。
2. 存储的位置不同；B+树中的数据都存储在叶子结点上，也就是其所有叶子结点的数据组合起来就是完整的数据，但是B树的数据存储在每一个结点中，并不仅仅存储在叶子结点上。而且B+树叶子结点上还存储了指向与该结点相邻的后一个叶子结点的指针信息，这主要是为了加快检索多个相邻叶子结点的效率考虑。
3. 分支结点的构造不同；分支结点并不存储真正的信息，仅包含着索引信息，其保存着叶子节点的最小值作为索引及其儿子指针（指的是磁盘块的偏移量）。【注：此处有争议，是以最大值还是最小值作为索引看个人实现】。
4. 查询不同；B树在找到具体的数值以后，则结束，而B+树则需要通过索引找到叶子结点中的数据才结束，也就是说B+树的搜索过程中走了一条从根结点到叶子结点的路径。
5. 用处不用：由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引，而B树则常用于文件索引
B+树索引
数据库中的B+Tree索引可以分为聚集索引（clustered index）和辅助索引（secondary index）。上面的B+Tree示例图在数据库中的实现即为聚集索引，聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据。辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据，而是存储相应行数据的聚集索引键，即主键。当通过辅助索引来查询数据时，InnoDB存储引擎会遍历辅助索引找到主键，然后再通过主键在聚集索引中找到完整的行记录数据。
聚集索引 和 辅助索引区别：叶子节点存放的是否是一整行的信息
聚集索引
聚集索引 ( clustered index ) 按照每张表的主键构造一棵 B+树，同时叶子节点存放的为整张表的行记录数据，也将聚集索引的叶子节点称为数据页。由于实际的数据页只能按照一棵B+树进行排序，所以每张表只能拥有一个聚集索引。查询优化器倾向于采用聚集索引。聚集索引能在B+树索引的叶节点上直接找到数据，是由于定义了数据的逻辑顺序。聚集索引适用于针对范围值的查询。
优点：对于主键排序查找和范围查找速度非常快。
辅助索引 ( 非聚集索引 )
辅助索 ( secondary index ) ，叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点中的索引行中还包含了一个书签 ( bookmark ) 。 该书签用来告诉 InnoDB 存储引擎哪里可以找到与索引相对应的行数据。每张表上可以有多个辅助索引，通过辅助索引查找数据时， InnoDB 存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，再通过主键索引找到完事的行记录。
HASH索引
Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，代表数据库：redis、memcache等
Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree索引。
可能很多人又有疑问了，既然Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。
1. Hash索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。
由于 Hash 索引比较的是进行 Hash 运算之后的 Hash值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。
2. Hash 索引无法被用来避免数据的排序操作。
由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash值，而且Hash值的大小关系并不一定和 Hash运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；
3. Hash索引不能利用部分索引键查询。
对于组合索引，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。
4. Hash索引在任何时候都不能避免表扫描。
前面已经知道，Hash 索引是将索引键通过 Hash 运算之后，将 Hash运算结果的 Hash值和所对应的行指针信息存放于一个 Hash 表中，由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。
5. Hash索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。
选择性比较低的索引键，如果创建 Hash 索引，那么将会存在大量记录指针信息存于同一个Hash值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下
Innodb特性（也就是使用了B+树索引，B+树索引分两种，上面有介绍）
InnoDB存储引擎中默认每个页的大小为16KB，InnoDB在把磁盘数据读入到磁盘时会以页为基本单位，B-Tree结构的数据可以让系统高效的找到数据所在的磁盘块。
一种是 Cluster 形式的主键索引（Primary Key），另外一种则是和其他存储引擎（如 MyISAM 存储引擎）存放形式基本相同的普通 B-Tree 索引，这种索引在 Innodb存储引擎中被称为 Secondary Index。下面我们通过图示来针对这两种索引的存放形式做一个比较。
图示中左边为 Clustered 形式存放的 Primary Key ，右侧则为普通的 B-Tree 索引。两种 Root Node和 Branch Nodes 方面都还是完全一样的。而 Leaf Nodes 就出现差异了。在 Prim中， Leaf Nodes存放的是表的实际数据，不仅仅包括主键字段的数据，还包括其他字段的数据据以主键值有序的排列。而 Secondary Index则和其他普通的 B-Tree 索引没有太大的差异，Leaf Nodes 出了存放索引键的相关信息外，还存放了Innodb的主键值。
所以，在 Innodb 中如果通过主键来访问数据效率是非常高的，而如果是通过 Secondary Index 来访问数据的话，Innodb 首先通过 Secondary Index 的相关信息，通过相应的索引键检索到 Leaf Node之后，需要再通过Leaf Node 中存放的主键值再通过主键索引来获取相应的数据行。MyISAM存储引擎的主键索引和非主键索引差别很小，只不过是主键索引的索引键是一个唯一且非空 的键而已。而且 MyISAM 存储引擎的索引和Innodb 的 Secondary Index 的存储结构也基本相同，主要的区别只是 MyISAM 存储引擎在 Leaf Nodes上面出了存放索引键信息之外，再存放能直接定位到 MyISAM 数据文件中相应的数据行的信息（如 Row Number），但并不会存放主键的键值信息