• MySql索引之BTree详解


    BTree索引

    BTree又叫多路平衡查找树,一颗m叉的BTree特性如下:

    • 树中每个节点最多包含m个孩子。
    • 除根节点与叶子节点外,每个节点至少有[ceil(m/2)]个孩子(ceil()为向上取整)。
    • 若根节点不是叶子节点,则至少有两个孩子。
    • 所有的叶子节点都在同一层。
    • 每个非叶子节点由n个key与n+1个指针组成,其中[ceil(m/2)-1] <= n <= m-1 。

    这是一个3叉(只是举例,真实会有很多叉)的BTree结构图,每一个方框块我们称之为一个磁盘块或者叫做一个block块,这是操作系统一次IO往内存中读的内容,一个块对应四个扇区,紫色代表的是磁盘块中的数据key,黄色代表的是数据data,蓝色代表的是指针p,指向下一个磁盘块的位置。

    来模拟下查找key为29的data的过程:

    1、根据根结点指针读取文件目录的根磁盘块1。【磁盘IO操作1次

    2、磁盘块1存储17,35和三个指针数据。我们发现17<29<35,因此我们找到指针p2。

    3、根据p2指针,我们定位并读取磁盘块3。【磁盘IO操作2次

    4、磁盘块3存储26,30和三个指针数据。我们发现26<29<30,因此我们找到指针p2。

    5、根据p2指针,我们定位并读取磁盘块8。【磁盘IO操作3次

    6、磁盘块8中存储28,29。我们找到29,获取29所对应的数据data。

    由此可见,BTree索引使每次磁盘I/O取到内存的数据都发挥了作用,从而提高了查询效率。

    但是有没有什么可优化的地方呢?

    我们从图上可以看到,每个节点中不仅包含数据的key值,还有data值。而每一个页的存储空间是有限的,如果data数据较大时将会导致每个节点(即一个页)能存储的key的数量很小,当存储的数据量很大时同样会导致B-Tree的深度较大,增大查询时的磁盘I/O次数,进而影响查询效率。

    B+Tree索引

    B+Tree是在B-Tree基础上的一种优化,使其更适合实现外存储索引结构。在B+Tree中,所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上,而非叶子节点上只存储key值信息,这样可以大大加大每个节点存储的key值数量,降低B+Tree的高度。

    B+Tree相对于B-Tree有几点不同:

    非叶子节点只存储键值信息, 数据记录都存放在叶子节点中, 将上一节中的B-Tree优化,由于B+Tree的非叶子节点只存储键值信息,所以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亿 条记录。(这种计算方式存在误差,而且没有计算叶子节点,如果计算叶子节点其实是深度为4了)

    我们只需要进行三次的IO操作就可以从10亿条数据中找到我们想要的数据,比起最开始的百万数据9000秒不知道好了多少个华莱士了。

    而且在B+Tree上通常有两个头指针,一个指向根节点,另一个指向关键字最小的叶子节点,而且所有叶子节点(即数据节点)之间是一种链式环结构。所以我们除了可以对B+Tree进行主键的范围查找和分页查找,还可以从根节点开始,进行随机查找。

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

    上面的B+Tree示例图在数据库中的实现即为聚集索引,聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据,辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据,而是存储相应行数据的聚集索引键,即主键。

    当通过辅助索引来查询数据时,InnoDB存储引擎会遍历辅助索引找到主键,然后再通过主键在聚集索引中找到完整的行记录数据。

    不过,虽然索引可以加快查询速度,提高 MySQL 的处理性能,但是过多地使用索引也会造成以下弊端

    • 创建索引和维护索引要耗费时间,这种时间随着数据量的增加而增加。
    • 除了数据表占数据空间之外,每一个索引还要占一定的物理空间。如果要建立聚簇索引,那么需要的空间就会更大。
    • 当对表中的数据进行增加、删除和修改的时候,索引也要动态地维护,这样就降低了数据的维护速度。

    注意:索引可以在一些情况下加速查询,但是在某些情况下,会降低效率。

    索引只是提高效率的一个因素,因此在建立索引的时候应该遵循以下原则:

    • 在经常需要搜索的列上建立索引,可以加快搜索的速度。
    • 在作为主键的列上创建索引,强制该列的唯一性,并组织表中数据的排列结构。
    • 在经常使用表连接的列上创建索引,这些列主要是一些外键,可以加快表连接的速度。
    • 在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,所以其指定的范围是连续的。
    • 在经常需要排序的列上创建索引,因为索引已经排序,所以查询时可以利用索引的排序,加快排序查询。
    • 在经常使用 WHERE 子句的列上创建索引,加快条件的判断速度。

    原文链接:https://juejin.im/post/6869532756498448392
  • 相关阅读:
    redis学习
    win2008下c#调用directshow问题
    vs2005升级到vs2010相关问题
    spark-shell 启动失败,显示端口问题
    监控spark-sql 等脚本
    spark 相关配置 shuffle 相关配置选项
    spark on Yarn 语句
    使用hive thriftserver 连接spark sql
    HBase 报错系列之region is not online
    HBase 表迁移中对丢失的表检查使用的语句
  • 原文地址:https://www.cnblogs.com/uzxin/p/13650143.html
Copyright © 2020-2023  润新知