• 207 MySQL索引的数据结构B+树介绍


    一、树

    树状图是一种数据结构 ,它是由n(n>=1)个有限结点组成一个具有层次关系的集合。把它叫做“树”是因为它看起来像一棵倒挂的树,也就是说它是根朝上,而叶朝下的。
    它具有以下的特点:每个结点有零个或多个子结点;没有父结点的结点称为根结点;每一个非根结点有且只有一个父结点;除了根结点外,每个子结点可以分为多个不相交的子树

    205-MySQL索引的数据结构-B树介绍-01.png?x-oss-process=style/watermark

    根结点:A

    父节点:A是B,C的父节点

    叶子节点:D,E是叶子节点

    树的深度/树的高度:高度为3

    二、B+树

    前面讲了索引的基本原理,数据库的复杂性,又讲了操作系统的相关知识,目的就是让大家了解,任何一种数据结构都不是凭空产生的,一定会有它的背景和使用场景,我们现在总结一下,我们需要这种数据结构能够做些什么,其实很简单,那就是:每次查找数据时把磁盘IO次数控制在一个很小的数量级,最好是常数数量级。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢?就这样,b+树应运而生(B+树是通过二叉查找树,再由平衡二叉树,B树演化而来)。

    205-MySQL索引的数据结构-B树介绍-02.png?x-oss-process=style/watermark

    2.1 B+树性质

    1. 索引字段要尽量的小:通过上面的分析,我们知道IO次数取决于b+数的高度h,假设当前数据表的数据为N,每个磁盘块的数据项的数量是m,则有h=㏒(m+1)N,当数据量N一定的情况下,m越大,h越小;而m = 磁盘块的大小 / 数据项的大小,磁盘块的大小也就是一个数据页的大小,是固定的,如果数据项占的空间越小,数据项的数量越多,树的高度越低。这就是为什么每个数据项,即索引字段要尽量的小,比如int占4字节,要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点,一旦放到内层节点,磁盘块的数据项会大幅度下降,导致树增高。当数据项等于1时将会退化成线性表。
    2. 索引的最左匹配特性:当b+树的数据项是复合的数据结构,比如(name,age,sex)的时候,b+数是按照从左到右的顺序来建立搜索树的,比如当(张三,20,F)这样的数据来检索的时候,b+树会优先比较name来确定下一步的所搜方向,如果name相同再依次比较age和sex,最后得到检索的数据;但当(20,F)这样的没有name的数据来的时候,b+树就不知道下一步该查哪个节点,因为建立搜索树的时候name就是第一个比较因子,必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时,b+树可以用name来指定搜索方向,但下一个字段age的缺失,所以只能把名字等于张三的数据都找到,然后再匹配性别是F的数据了, 这个是非常重要的性质,即索引的最左匹配特性。

    三、聚集索引和辅助索引

    在数据库中,B+树的高度一般都在2~4层,这也就是说查找某一个键值的行记录时最多只需要2到4次IO,这倒不错。因为当前一般的机械硬盘每秒至少可以做100次IO,2~4次的IO意味着查询时间只需要0.02~0.04秒。

    数据库中的B+树索引可以分为聚集索引(clustered index)和辅助索引(secondary index),

    聚集索引与辅助索引相同的是:不管是聚集索引还是辅助索引,其内部都是B+树的形式,即高度是平衡的,叶子结点存放着所有的数据。

    聚集索引与辅助索引不同的是:叶子结点存放的是否是一整行的信息

    3.1 聚集索引

    InnoDB存储引擎表是索引组织表,即表中数据按照主键顺序存放。
    而聚集索引(clustered index)就是按照每张表的主键构造一棵B+树,同时叶子结点存放的即为整张表的行记录数据,也将聚集索引的叶子结点称为数据页。
    聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。同B+树数据结构一样,每个数据页都通过一个双向链表来进行链接。

    如果未定义主键,MySQL取第一个唯一索引(unique)而且只含非空列(NOT NULL)作为主键,InnoDB使用它作为聚簇索引。

    如果没有这样的列,InnoDB就自己产生一个这样的ID值,它有六个字节,而且是隐藏的,使其作为聚簇索引。

    由于实际的数据页只能按照一棵B+树进行排序,因此每张表只能拥有一个聚集索引。
    在多数情况下,查询优化器倾向于采用聚集索引。因为聚集索引能够在B+树索引的叶子节点上直接找到数据。
    此外由于定义了数据的逻辑顺序,聚集索引能够特别快地访问针对范围值得查询。

    205-MySQL索引的数据结构-B树介绍-13.png?x-oss-process=style/watermark

    聚集索引的好处之一:它对主键的排序查找和范围查找速度非常快,叶子节点的数据就是用户所要查询的数据。如用户需要查找一张表,查询最后的10位用户信息,由于B+树索引是双向链表,所以用户可以快速找到最后一个数据页,并取出10条记录

    # 参照第六小结测试索引的准备阶段来创建出表s1
    mysql> desc s1; #最开始没有主键
    +--------+-------------+------+-----+---------+-------+
    | Field  | Type        | Null | Key | Default | Extra |
    +--------+-------------+------+-----+---------+-------+
    | id     | int(11)     | NO   |     | NULL    |       |
    | name   | varchar(20) | YES  |     | NULL    |       |
    | gender | char(6)     | YES  |     | NULL    |       |
    | email  | varchar(50) | YES  |     | NULL    |       |
    +--------+-------------+------+-----+---------+-------+
    rows in set (0.00 sec)
    
    mysql> explain select * from s1 order by id desc limit 10; #Using filesort,需要二次排序
    +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+----------------+
    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra          |
    +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+----------------+
    |  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 2633472 |   100.00 | Using filesort |
    +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+----------------+
    row in set, 1 warning (0.11 sec)
    
    mysql> alter table s1 add primary key(id); #添加主键
    Query OK, 0 rows affected (13.37 sec)
    Records: 0  Duplicates: 0  Warnings: 0
    
    mysql> explain select * from s1 order by id desc limit 10; #基于主键的聚集索引在创建完毕后就已经完成了排序,无需二次排序
    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------+
    | id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra |
    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------+
    |  1 | SIMPLE      | s1    | NULL       | index | NULL          | PRIMARY | 4       | NULL |   10 |   100.00 | NULL  |
    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------+
    row in set, 1 warning (0.04 sec)
    

    聚集索引的好处之二:范围查询(range query),即如果要查找主键某一范围内的数据,通过叶子节点的上层中间节点就可以得到页的范围,之后直接读取数据页即可

    mysql> alter table s1 drop primary key;
    Query OK, 2699998 rows affected (24.23 sec)
    Records: 2699998  Duplicates: 0  Warnings: 0
    
    mysql> desc s1;
    +--------+-------------+------+-----+---------+-------+
    | Field  | Type        | Null | Key | Default | Extra |
    +--------+-------------+------+-----+---------+-------+
    | id     | int(11)     | NO   |     | NULL    |       |
    | name   | varchar(20) | YES  |     | NULL    |       |
    | gender | char(6)     | YES  |     | NULL    |       |
    | email  | varchar(50) | YES  |     | NULL    |       |
    +--------+-------------+------+-----+---------+-------+
    rows in set (0.12 sec)
    
    mysql> explain select * from s1 where id > 1 and id < 1000000; # 没有聚集索引,预估需要检索的rows数如下
    +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
    | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra       |
    +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
    |  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 2690100 |    11.11 | Using where |
    +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
    row in set, 1 warning (0.00 sec)
    
    mysql> alter table s1 add primary key(id);
    Query OK, 0 rows affected (16.25 sec)
    Records: 0  Duplicates: 0  Warnings: 0
    
    mysql> explain select * from s1 where id > 1 and id < 1000000; # 有聚集索引,预估需要检索的rows数如下
    +----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
    | id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows    | filtered | Extra       |
    +----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
    |  1 | SIMPLE      | s1    | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL | 1343355 |   100.00 | Using where |
    +----+-------------+-------+------------+-------+---------------+---------+---------+------+---------+----------+-------------+
    row in set, 1 warning (0.09 sec)
    

    3.2 辅助索引

    表中除了聚集索引外其他索引都是辅助索引(Secondary Index,也称为非聚集索引),与聚集索引的区别是:辅助索引的叶子节点不包含行记录的全部数据。

    叶子节点除了包含键值以外,每个叶子节点中的索引行中还包含一个书签(bookmark)。该书签用来告诉InnoDB存储引擎去哪里可以找到与索引相对应的行数据。

    由于InnoDB存储引擎是索引组织表,因此InnoDB存储引擎的辅助索引的书签就是相应行数据的聚集索引键。如下图

    205-MySQL索引的数据结构-B树介绍-14.png?x-oss-process=style/watermark

    辅助索引的存在并不影响数据在聚集索引中的组织,因此每张表上可以有多个辅助索引,但只能有一个聚集索引。当通过辅助索引来寻找数据时,InnoDB存储引擎会遍历辅助索引并通过叶子级别的指针获得只想主键索引的主键,然后再通过主键索引来找到一个完整的行记录。

    举例来说,如果在一棵高度为3的辅助索引树种查找数据,那需要对这个辅助索引树遍历3次找到指定主键,如果聚集索引树的高度同样为3,那么还需要对聚集索引树进行3次查找,最终找到一个完整的行数据所在的页,因此一共需要6次逻辑IO访问才能得到最终的一个数据页。

    205-MySQL索引的数据结构-B树介绍-15.png?x-oss-process=style/watermark

    3.3 聚集索引和非聚集索引的区别

    聚集索引

    1. 纪录的索引顺序与无力顺序相同
      因此更适合between and和order by操作
    2. 叶子结点直接对应数据
      从中间级的索引页的索引行直接对应数据页
    3. 每张表只能创建一个聚集索引

    非聚集索引

    1. 索引顺序和物理顺序无关
    2. 叶子结点不直接指向数据页
    3. 每张表可以有多个非聚集索引,需要更多磁盘和内容
    4. 多个索引会影响insert和update的速度

    四、再看B+树

    B+树和二叉树、平衡二叉树一样,都是经典的数据结构。B+树由B树和索引顺序访问方法(ISAM,是不是很熟悉?对,这也是MyISAM引擎最初参考的数据结构)演化而来,但是在实际使用过程中几乎已经没有使用B树的情况了。

    B+树的定义十分复杂,因此只简要地介绍B+树:B+树是为磁盘或其他直接存取辅助设备而设计的一种平衡查找树,在B+树中,所有记录节点都是按键值的大小顺序存放在同一层的叶节点中,各叶节点指针进行连接。

    我们先来看一个B+树,其高度为2,每页可存放4条记录,扇出(fan out)为5。

    205-MySQL索引的数据结构-B树介绍-03.png?x-oss-process=style/watermark

    可以看出,所有记录都在叶节点中,并且是顺序存放的,如果我们从最左边的叶节点开始顺序遍历,可以得到所有键值的顺序排序:5、10、15、20、25、30、50、55、60、65、75、80、85、90。

    4.1 B+树的插入操作

    B+树的插入必须保证插入后叶节点中的记录依然排序,同时需要考虑插入B+树的三种情况,每种情况都可能会导致不同的插入算法,如表5-1所示。

    205-MySQL索引的数据结构-B树介绍-04.png?x-oss-process=style/watermark

    我们用实例来分析B+树的插入,我们插入28这个键值,发现当前Leaf Page和Index Page都没有满,我们直接插入就可以了。

    205-MySQL索引的数据结构-B树介绍-05.png?x-oss-process=style/watermark

    这次我们再插入一条70这个键值,这时原先的Leaf Page已经满了,但是Index Page还没有满,符合表5-1的第二种情况,这时插入Leaf Page后的情况为50、55、60、65、70。我们根据中间的值60拆分叶节点。

    205-MySQL索引的数据结构-B树介绍-06.png?x-oss-process=style/watermark

    因为图片显示的关系,这次我没有能在各叶节点加上双向链表指针。最后我们来插入记录95,这时符合表5-1讨论的第三种情况,即Leaf Page和Index Page都满了,这时需要做两次拆分。

    205-MySQL索引的数据结构-B树介绍-07.png?x-oss-process=style/watermark

    可以看到,不管怎么变化,B+树总是会保持平衡。但是为了保持平衡,对于新插入的键值可能需要做大量的拆分页(split)操作,而B+树主要用于磁盘,因此页的拆分意味着磁盘的操作,应该在可能的情况下尽量减少页的拆分。因此,B+树提供了旋转(rotation)的功能。

    旋转发生在Leaf Page已经满了、但是其左右兄弟节点没有满的情况下。(旋转是为了减少拆分页,如果叶子节点的左右兄弟节点还有空位置,那就旋转一下就能把当前数据插入了;如果自己和左右兄弟位置都满了那再怎么旋转也出不来位置了,只能拆分页了)这时B+树并不会急于去做拆分页的操作,而是将记录移到所在页的兄弟节点上。通常情况下,左兄弟被首先检查用来做旋转操作,这时我们插入键值70,其实B+树并不会急于去拆分叶节点,而是做旋转,50,55,55旋转。

    205-MySQL索引的数据结构-B树介绍-08.png?x-oss-process=style/watermark

    可以看到,采用旋转操作使B+树减少了一次页的拆分操作,而这时B+树的高度依然还是2。

    4.2 B+树的删除操作

    B+树使用填充因子(fill factor)来控制树的删除变化,50%是填充因子可设的最小值。B+树的删除操作同样必须保证删除后叶节点中的记录依然排序,同插入一样,B+树的删除操作同样需要考虑如表5-2所示的三种情况,与插入不同的是,删除根据填充因子的变化来衡量。

    205-MySQL索引的数据结构-B树介绍-09.png?x-oss-process=style/watermark

    首先,删除键值为70的这条记录,该记录符合表5-2讨论的第一种情况,删除后。

    205-MySQL索引的数据结构-B树介绍-10.png?x-oss-process=style/watermark

    接着我们删除键值为25的记录,这也是表5-2讨论的第一种情况,但是该值还是Index Page中的值,因此在删除Leaf Page中25的值后,还应将25的右兄弟节点的28更新到Page Index中,最后可得到图。

    205-MySQL索引的数据结构-B树介绍-11.png?x-oss-process=style/watermark

    最后我们来看删除键值为60的情况,删除Leaf Page中键值为60的记录后,填充因子小于50%,这时需要做合并操作,同样,在删除Index Page中相关记录后需要做Index Page的合并操作,最后得到图。

    205-MySQL索引的数据结构-B树介绍-12.png?x-oss-process=style/watermark

  • 相关阅读:
    移动硬盘无法识别提示需要格式化的解决办法
    Cassandra 入门(资料收集)
    [转] NoSQL生态系统
    软件项目实施问题收集(LastUpdatedOn:20141117)
    Sql server 收缩日志
    关于重构需要了解的一些原则
    C#定时任务采用线程和队列实现
    [转]我是如何带领团队开发项目的
    ASP.NET MVC 多套皮肤解决方案
    Mysql 问题汇总(不断更新中...)
  • 原文地址:https://www.cnblogs.com/abdm-989/p/11991258.html
Copyright © 2020-2023  润新知