MySQL索引的数据结构

第06章 索引的数据结构

1.为什么使用索引？

索引是存储引擎用于快速找到数据记录的一种数据结构。MySQL中也是一样的道理，进行数据查找时，首先查看查询条件是否命中某条索引，符合则通过索引查找相关数据，如果不符合则需要全表扫描，即需要一条一条地查找记录，直到找到与条件符合的记录。

2.索引及其优缺点

2.1 索引概述

索引（Index）是帮助MySQL高效获取数据的数据结构。
索引的本质：索引是数据结构。你可以简单理解为“排好序的快速查找数据结构”，满足特定查找算法。 这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法。
索引是在存储引擎中实现的，因此每种存储引擎的索引不一定完全相同。

2.2 优点

• 降低数据库的磁盘IO成本
• 唯一索引可以保证数据库表中每一行的数据唯一性。
• 在数据完整性方面，加速了子表和主表联合查询时的查询速度。
• 显著降低查询中分组和排序的CPU消耗。

2.3 索引的缺点

1. 创建索引和维护索引要耗费时间，随着数据量大增加耗费的时间也要增加。
2. 索引需要占用磁盘空间
3. 提高了查询速度，但降低了更新表的速度。因为更新表时也需要对索引动态维护。

提示：
索引可以提高查询的速度，但是会影响插入记录的速度。这种情况下，最好的办法是先删除表中的索引，然后插入数据，插入完成后再创建索引。

3.InnoDB中索引的推演

3.1 索引之前的查找

1.在一个页中查找

所有记录在一个页中，分为两种情况：

• 以主键为搜索条件
  可以在页目录中使用 二分法 快速定位到对应的槽，然后再遍历该槽对用分组中的记录即可快速找到指定记录。
• 以其他列为搜索条件只能顺序查找，只能从最小记录开始依次遍历单链表中的每条记录，判断是否符合条件。
• 页中的记录是以单链表进行连接的。

2. 在很多页中查找

在很多页中查找记录的活动可以分为两个步骤：

1. 定位到记录所在的页。
2. 从所在的页内中查找相应的记录。
   因此没有索引的情况下，无法进行快速定位到记录所在的页，只能沿着双向链表一直向下找，因此要遍历所有的数据页。

3.2 设计索引（引出B+树的过程）

建一个名为index_demo的表，其中c1是主键，而这个表使用的是Compact行格式记录存储记录。

示意图中的记录展示如下：

• record_type：记录头信息的一项属性，表示记录的类型， 0表示普通记录、 2 表示最小记录、 3 表示最大记录、 1 暂时还没用过，下面讲。
• next_record：表示下一条地址相对于本条记录的地址偏移量。
• 各个列的值：index_demo表中的列c1,c2和c3。
• 其他信息：其他隐藏列的值和记录的额外信息。
  将示意图竖起来就表示如下图所示：
  
  记录在页中的数据表示：
  

1. 一个简单的索引设计方案

为了能够快速定位到需要查找的记录所在的数据页，需要建立一个索引目录。将一个数据页存放3条记录，按照主键值的按大小排序串联成一个单向链表。

约束：下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。
再添加一条记录，就需要分配一个新页。

新分配的数据页编号可能并不是连续的，页号只是用于维护链表关系，插入的值仍需要按照之前的有序顺序，因此会发生记录移动保证有序的约束。这个过程称为页分裂。

• 考虑所有的页时，数据页的编号是不连续的，需要给所有的页建立一个目录项。
  
  给每个页做一个新的目录，使得每个页对应一个目录项，每个目录项包括下边两个部分：
  1）页的用户记录中最小的主键值，我们用 key 来表示。
  2）页号，我们用 page_on 表示。
  
  只需要使得目录项在物理存储器上连续存储，就可以根据主键快速查找到某条记录。
  比如：查找主键值为 20 的记录，具体查找过程分两步：

1. 先从目录项中根据二分法快速确定出主键值为20的记录在目录项3中（因为 12 < 20 < 209），它对应的页。
2. 再根据前边说的在页中查找记录的方式去页9中定位具体的记录。
   至此，针对数据页做的简易目录就搞定了。这个目录有一个别名，称为索引。

2. InnoDB中的索引方案

① 迭代1次：目录项记录的页（将目录项使用链表连接）

InnoDB使用记录头信息里的record_type属性来区分用户记录 还是 目录项记录，具体取值的含义如下：

• 0：普通的用户记录
• 1：目录项记录
• 2：最小记录
• 3：最大记录
  
  以查找主键20为例，只需要两次IO：

1. 到存储目录项记录的页，通过二分法快速定位到对应的目录项，比如就是页9.
2. 再到存储用户记录的页目录根据二分法快速定位到主键为20的用户记录。

② 迭代2次：多个目录项记录的页

现在存储目录项记录的页不止一个，因此根据主键值查找一条记录变成3个步骤：

1. 确定目录项记录页的位置，如页30.
2. 通过目录项记录页定位记录所在的页。
3. 在用户记录页中定位具体记录。

③ 迭代3次：目录项记录页的目录页

当表中数据很多将会产生很多存储目录项记录的页，因此需要生成一个更高级的目录，就像是一个多级目录一样，大目录里嵌套小目录，小目录里才是实际的数据。

如图，我们生成了一个存储更高级目录项的 页33 ，这个页中的两条记录分别代表页30和页32，如果用户记录的主键值在 [1, 320) 之间，则到页30中查找更详细的目录项记录，如果主键值不小于320的话，就到页32中查找更详细的目录项记录。

每一个节点就是一个数据页，叶子节点是真实存放的数据，节点内是单向链表之间连接，叶子节点之间是双向链表连接。这个数据结构就是B+数。

④ B+Tree（需要表达出来）

默认的数据页大小是16KB，假设叶子节点的数据页可以存放100条用户记录，存放目录项记录的非叶子节点可以存放1000条目录项记录。
如果B+树有4层，就可以存放1亿条记录。
一般情况下，B+数都不会超过4层，那我们通过主键值去查找某条记录最多只需要做4个页面内的查找（查找3个目录项页和1个用户记录页），又因为在每个页面内有所谓的Page Directory （页目录），所以在页面内也可以通过二分法实现快速定位记录。

树的层次越低，IO的次数就会越少。

3.3 （重点）常见索引概念

索引按照物理实现方式，可以分为：聚簇索引和非聚簇索引。

1. 聚簇索引

术语"聚簇"表示当前数据行和相邻的键值聚簇的存储在一起，表中的数据和索引是存储在一起的。
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式（所有的用户记录都存储在了叶子结点），也就是所谓的索引即数据，数据即索引。
特点：

• 使用记录主键值的大小进行记录和页的排序，这包括三个方面的含义：
  • 页内的记录是按照主键的大小顺序排成一个单向链表。
  • 各个存放用户记录的页是根据页中用户记录的主键大小顺序排成一个双向链表。
  • 存放目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的主键大小顺序排成一个双向链表。
• B+树的叶子节点存储的是完整的用户记录。
  • 所谓完整的用户记录，就是指这个记录中存储了所有列的值（包括隐藏列）。
    我们把具有这两种特性的B+树称为聚簇索引，所有完整的用户记录都存放在这个聚簇索引的叶子节点处。这种聚簇索引并不需要我们在MySQL语句中显式的使用INDEX语句去创建， InnoDB 存储引擎会自动的为我们创建聚簇索引，是在添加数据过程中边添加边生成索引。
    优点：

• 数据访问更快 ，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更快
• 聚簇索引对于主键的 排序查找 和 范围查找 速度非常快
• 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以 节省了大量的io操作
  缺点：
• 插入速度严重依赖于插入顺序 ，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。
• 更新主键的代价很高 ，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新
• 二级索引访问需要两次索引查找 ，第一次找到主键值，第二次根据主键值找到行数据

限制：

• MySQL数据库只有InnoDB引擎支持聚簇索引，而MyISAM不支持聚簇索引
• 每个表中只能有一个聚簇索引，一般情况下就是该表的主键。（因为数据的物理存储排序方式只有一种）
• 如果没有定义主键，InnoDB会选择非空的唯一索引代替。如果没有这样的索引，InnoDB会隐式定义一个主键作为聚簇索引。
• InnoDB表的主键列建议使用有序的顺序ID，而不是无序的id，比如UUID/MD5/HASH/字符串列作为主键，它们无法保证数据的顺序增长。

2.二级索引（非聚簇索引）

聚簇索引只能在搜索条件是主键值的时候，才能使用，因为B+树的数据都是按照主键进行排序的。
如果以别的列作为搜索条件，就可以根据对应的列构建B+树，不同的B+树采用不同的排序规则。例如，以c2升序排列数据构建B+树。

以c2列构建的非聚簇索引的B+树与聚簇索引的不同：

• 使用记录c2列的大小进行记录和页的排序
  • 页内的记录是按照c2列的大小顺序排成一个单向链表
  • 各个存放用户记录的页是根据页中记录的c2列大小顺序排成双向链表。
  • 存放目录项记录的页分为不同的层次，在同一层次中的列，也是根据页中目录项记录c2列的大小顺序排成一个双向链表。
• 聚簇索引B+树的叶子节点存放的是完整的用户记录，而当前B+树存放的是c2列+主键这两个列的值。
• 目录项存放的不再是主键+页号，而是c2列+页号的模式。
  通过c2列查找某些记录就使用到该B+树了，查找c2=4的记录为例：

1. 确定目录项记录页的位置。
   根据根页面(页44)，快速定位到目录项记录所在的页42(因为2<4<9)
2. 通过目录项记录页确定用户记录所在的页
   在页42可以快速定位到用户记录实际所在的页，由于c2列没有唯一性约束，所以c2列值为4的记录可能分布于多个数据页中，又因为2<4<=4，所以确定实际存储用户记录的页在页34和页35之间，
3. 在用户记录页中定位具体记录
   到页34和页35中定位具体的记录。
4. 但非聚簇索引的B+树只存储了c2和c1(主键)这两个列，必须再根据主键值去聚簇索引的B+树中查找一次完整的用户记录。

c2列构建的二级索引是不存在c3列（字符列）的，可以通过叶子节点判断它不是聚簇索引。
以下是C2=4的查找情况，如果需要C3列，使用主键值C1去聚簇索引中C3的值，这个过程称之为回表。

概念：回表
我们根据这个以c2列大小排序的B+树只能确定我们要查找记录的主键值，所以如果要根据c2列的值查找到完整的用户记录的话，仍然需要到聚簇索引中再查一遍，这个过程称为回表。也就是根据c2列的值查询一条完整的用户记录需要使用到2棵B+树！
为什么非聚簇索引不保留完整的用户数据
如果不需要回表，就意味着将完整的用户记录放到叶子结点中，但相当于每建立一颗B+树就需要拷贝全部的用户记录（每个字段中的全部数据）。一个表可以有多个非聚簇索引，因此会占用太大的空间。

因为这种按照非主键列建立的B+树需要一次回表操作才可以定位到完整的用户记录，所以这种B+树也被称为二级索引，或者辅助索引。由于使用的是c2列的大小作为B+树的排序规则，所以我们也称这个B+树为c2列建立的索引。

小结：
聚簇索引和非聚簇索引的不同：

1. InnoDB引擎中，一个表的存储结构只能对应一个主键并由主键建立，因此只存在一个聚簇索引。其他字段建立的索引都是非聚簇索引，因此可以有多个非聚簇索引。
2. 聚簇索引的叶子节点存储的就是用户的完整记录，非聚簇索引中的叶子节点存储的是数据位置，非聚簇索引不会影响数据表的物理存储顺序。

3.联合索引（非聚簇索引的一种）

一些情况下，可以同时以多个列的大小作为排序规则，即同时为多个列建立索引，比如需要按照c2和c3列上大小进行排序，含义如下：

• 先将各个记录和页按照c2列进行排序
• 在记录c2列相同的情况下，采用c3列进行排序。
  -

例如：c2=4,c3=u进行查找，从上到下找2，到第二层可能在<2,e>,<4,o>中，‘u’<‘o’，因此可能存在于<4,o>对应的表中；到达第三层，查找页55的表，就找到了<4,u>这条数据。
上图的总结为：

• B+树叶子节点处的用户记录由c2、c3和主键c1列组成，但实际上总共字段可能有多个其他列和隐藏列。
• 每条目录项都有c2、c3、页号这三个部分组成，各条记录先按照c2列的值进行排序，如果记录的c2列相同，则按照c3列的值进行排序。
• 联合索引本质上也是一个二级索引，与分别为c2和c3列分别建立索引的表述是不同的
  • 建立联合索引只会建立如上图一样的1棵B+树。
  • 为c2和c3列分别建立索引会分别以c2和c3列的大小为排序规则建立2棵B+树。

3.4 （重点） InnoDB的B+树索引注意事项

1.根页面位置万年不动

实际上B+树的形成过程是这样的：

• 每当为某个表创建一个B+树索引（聚簇索引不是人为创建的，默认就有）的时候，都会为这个索引创建一个 根结点 页面。最开始表中没有数据的时候，每个B+树索引对应的 根结点 中即没有用户记录，也没有目录项记录。
• 随后向表中插入用户记录时，先把用户记录存储到这个根节点 中。
• 当根节点中的可用 空间用完时 继续插入记录，此时会将根节点中的所有记录复制到一个新分配的页，比如 页a 中，然后对这个新页进行 页分裂 的操作，得到另一个新页，比如页b 。这时新插入的记录根据键值（也就是聚簇索引中的主键值，二级索引中对应的索引列的值）的大小就会被分配到 页a 或者 页b 中，而 根节点 便升级为存储目录项记录的页。

这个过程特别注意的是：一个B+树索引的根节点自诞生起，便不会再移动。这样只要我们对某个表建议一个索引，那么它的根节点的页号便会被记录到某个地方。然后凡是 InnoDB 存储引擎需要用到这个索引的时候，都会从哪个固定的地方取出根节点的页号，从而来访问这个索引。

2.内节点中目录项记录的唯一性（指的是非聚簇索引，非叶子节点中目录项的记录是唯一的）

B+树索引的内节点中目录项记录的内容是 索引列 + 页号 的搭配，但是这个搭配对于二级索引来说有点不严谨。还拿 index_demo 表为例，假设这个表中的数据是这样的：

如果叶子节点上只放当前列c2和主键 的值，那么B+树如下图
此时想添加一条新的数据为(9,1,c)，

为了让新插入记录找到自己在那个页面，我们需要保证在B+树的同一层页节点的目录项记录除页号这个字段以外是唯一的。所以对于二级索引的内节点的目录项记录的内容实际上是由三个部分构成的：

• 索引列的值
• 主键值
• 页号

也就是我们把主键值也添加到二级索引内节点中的目录项记录，这样就能保住 B+ 树每一层节点中各条目录项记录除页号这个字段外（c2列+主键值）是唯一的。
这时再插入记录(9, 1, ‘c’)时，新纪录就可以确定插入到页5中。

3. 一个页面最少存储 2 条记录

InnoDB 的一个数据页至少可以存放两条记录以便构成树状结构。

4. MyISAM中的索引方案

B树索引使用存储引擎如表所示：

索引 / 存储引擎	MyISAM	InnoDB	Memory
B-Tree索引	支持	支持	支持

MyISAM引擎使用B+Tree作为索引结构，叶子节点的data域存放的是数据记录的地址。

4.1 MyISAM索引的原理

• MyISAM将索引和数据分开进行存储；按照记录的插入顺序存储数据到一个数据文件中，不进行主键大小的排序，所以不能使用二分法查找。
• MyISAM将索引信息另外存储到索引文件中，索引文件仅仅保存数据记录的地址，MyISAM全部都是二级索引（非聚簇索引），而没有聚簇索引。
• MyISAM会单独为主键创建一个索引，它的叶子节点存储到是主键值 + 数据记录地址(.myd文件中的逻辑地址）。
  
  上图为MyISAM表的主索引示意图。MyISAM的索引文件仅保存数据记录的地址。MyISAM中主键索引和二级索引（非聚簇索引）在结构上没有区别，主键索引要求key是唯一的，而二级索引的key值可以重复。

4.2在MyISAM中构建二级索引的方式

• 如下图在Col2（普通字段）中构建一个二级索引，在col2字段上最底层进行排序，然后挑选每个页的最小值向上构建目录项。
• 注意，底层的叶子节点仍然记录的是地址值。
  
  总结：
  对于MyISAM构建的B+树，由于data域保存的数据存储到都是记录的地址，因此都是非聚簇索引。
  MyISAM索引检索的算法为：按照B+树搜索算法搜索索引，如果Key存在就取出data域的值，然后以data域的值为地址，读取相应的数据记录。

4.3 MyISAM 与 InnoDB索引的对比

MyISAM的索引方式是非聚簇的，InnoDB包含一个聚簇索引（数据即索引）。

1. InnoDB引擎只需要根据主键值的聚簇索引进行一次查询就可以查询到对应的记录，而MyISAM中需要进行回表操作（查找索引–>根据索引查找到地址值），MyISAM中建立的索引都是二级索引
2. InnoDB数据文件就是索引文件，MyISAM数据文件和索引文件是分离的，索引文件只保存数据记录的地址。
3. InnoDB的非聚簇索引data域存储的记录是主键的值，所有非聚簇索引都引用主键作为data域，MyISAM索引记录存储的是地址。
4. 对于非聚簇索引：MyISAM的回表操作是很快速的，因为是使用地址偏移量到文件中直接获取数据；InnoDB的查找还需要回到主键的聚簇索引中寻找地址。
5. InnoDB要求必须有主键（MyISAM可以没有主键）。如果没有显式指定，会自动选择一个非空且唯一标识数据记录的列作为主键；如果没有这样的列，会自动为InnoDB表生成一个隐含字段作为主键，这个字段的长度为6个字节，类型为长整型。

小结

1. 不建议使用过长的字段作为主键，因为InnoDB的所有二级索引都要引用主键索引，过长的主键索引会使得每页存放的数据条数减少，使得二级索引树变高。
2. 推荐使用具有单调性的主键，如果不单调的主键会使得数据文件维持B+树的特性而频繁地分裂调整，降低效率。

5.索引的代价（TODO：重述时间代价）

1. 空间上的代价
   创建一个索引就会建立一个B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会占用16KB的空间，B+树由很多数据页组成，是很大一片存储空间。
2. 时间上的代价
   对表中数据的增删改操作，需要维护各个B+树的索引。
   在B+树中，每层节点都是按照索引值 从小到大的顺序 排序而组成了双向链表。不论是叶子节点的用户记录，还是非叶子节点的目录项记录，都是按照索引值的从小到大的顺序形成的单向链表。
   而增删改操作会对节点和记录的顺序造成破坏，所以存储引擎会需要额外的时间进行记录移位、页面分裂、页面回收的操作来维护节点和记录的排序。如果建立了很多索引，就会造成性能的下降。

小结：
一个表上索引建立的越多，就会越占用存储空间，在增删改记录时的性能就越差。
需要掌握的部分是，判断是不是B+树，是聚簇索引还是非聚簇索引。

6. MySQL数据结构选择的合理性

为减少索引在内存中的占用，数据库索引是存储在外部硬盘上的，使用索引时不可能将索引全部加载到内存中，只能逐一加载，衡量MySQL查询效率的标准就是磁盘IO次数。
加快查找速度的数据结构，常见的有两类：
(1) 树，例如平衡二叉搜索树，查询/插入/修改/删除的平均时间复杂度都是 O(log2N);
(2)哈希，例如HashMap，查询/插入/修改/删除的平均时间复杂度都是 O(1); (key, value)
Hash结构效率高，那为什么索引结构要设计成树型呢？
原因：

1. Hash索引仅能判断=,<>,IN的查询。对于范围查询，哈希索引会退化成顺序查找；而树形有序的特性，能够一直保持O(logN)级别。
2. Hash的数据存储是无序的，ORDER BY是需要对数据重新排序。
3. Hash索引无法单独对一个或几个索引进行查询，对于联合索引键是合并后计算的一个值。<4,‘a’> = ❤️,‘b’>
4. Hash索引不适用于重复值多的列上；索引列的重复值很多时（如性别、年龄）会导致效率降低。因为遇到哈希冲突时，需要遍历桶中的行指针进行比较，找到查询的关键字，非常耗时。
   
   
   自适应 Hash 索引目的是方便根据 SQL 的查询条件加速定位到叶子节点，特别是当 B+ 树比较深的时候，通过自适应 Hash 索引可以明显提高数据的检索效率。
   哈希索引对等值判断的支持比较好。

6.3 二叉搜索树

1. 二叉搜索树的特点

• 一个节点只能有两个子节点，也就是一个节点的度不能超过2
• 左子节点 < 本节点; 右子节点 >= 本节点，比我大的向右，比我小的向左

2. 查找规则
   
   但是特殊情况，就是有时候二叉树的深度非常大，比如一个依次增大的数组数据：
   为了减少磁盘IO的次数吗，需要尽量降低树的高度，因此在二叉搜索树的基础上需要将树结构变得矮胖，树的每层分叉越多越好。

6.4 AVL树

为了解决二叉搜索树退化为链表的问题，提出了平衡二叉搜索树，又称为AVL树。
添加了以下约束：
它是一颗空树，或它的左右两个子树的高度差绝对值不超过1，并且左右两个子树都是一颗平衡二叉树。

针对同样的数据，如果我们把二叉树改成 M=3 叉树 （M>2）呢？

此时树的高度降低了，当数据量 N 大的时候，以及树的分叉树 M 大的时候，M叉树的高度会远小于二叉树的高度 (M > 2)。

6.5 B-Tree

B树(Balance Tree)就是多路平衡查找树，简写为B-Tree，它的高度远小于平衡二叉树的高度。

小结：

1. B树在插入或删除时到导致树不平衡，就会通过自动调整节点的位置来保持树的自平衡。
2. 关键字集合分布在整个树中，即叶子结点和非叶子结点都存放数据。搜索可能在非叶子结点结束。
   

6.6 B+树

B+树也是多路搜索树，基于B树进行了改进，B+Tree更适合文件系统。
B+ 树和 B 树的差异在于以下几点：

1. B+树中，k个孩子的节点就有k个关键字。孩子数量=关键字数，而B数中，孩子数量=关键字数+1
2. B+树中，非叶子结点的关键字会同时存在于子节点中，并且是子节点中所有关键字段最小（最大）
3. B+树中，非叶子节点仅用于索引，不保存数据记录，数据记录仅存放在叶子节点中。而在B树中，非叶子结点既保存索引，也保存数据记录。
4. B+树中，所有关键字都在叶子节点中出现，叶子节点构成一个有序链表，叶子节点按照关键字的大小从小到大顺序排列。而B树中，如果需要从小到大的排序需要使用中序遍历。
   B+树对于B树的改进：
5. B+树的查询效率更稳定，因为B+树每次只有访问叶子节点才能获取对应的数据。B树中非叶子节点也存放数据会导致查询效率的不稳定。
6. B+树的查询效率较高。B+树对B树的阶数更大，深度更低。查询所需要的磁盘IO更少，因为同样的磁盘页空间，B+树可以存储更多的节点关键字。
7. 在范围查找上，B+树的效率也比B树更高。因为在B+树中所有的关键字都出现在叶子结点，叶子结点之间有指针且数据有序，使得范围查找可以直接通过指针连接查找。而B树需要中序遍历才能完成范围查找。

思考题：B+树的存储能力如何？为何说一般查找行记录，最多只需1~3次磁盘IO？
InnoDB存储引擎的页大小是16KB，一般表的主键类型是4(INT)或8(BIGINT)个字节，指针类型是4个或8个，一个页中大概存储16KB/(8B+8B)= 1K个键值，取10^3。
假设一个目录页存储1000条数据，一个深度为3的B+Tree索引可以维护10³3 = 10亿条数据。
实际上每个节点可能不能填满，因此在数据库中，B+树的高度为2_{4层。InnoDB存储引擎的设计是将根节点常驻内存，也就是说查找某一键值的行记录时最多需要1}3次I/O操作。
思考题：为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？

思考题：Hash 索引与 B+ 树索引的区别

需要掌握的内容：识别B+树的数据结构，与B+树的区别，与哈希的区别。B+树作为索引结构出现的数据特征。