【9.数据页结构】

概述

  • InnoDB 的数据是按「数据页」为单位来读写的,也就是说,当需要读一条记录的时候,并不是将这个记录本身从磁盘读出来,而是以页为单位,将其整体读入内存。
  • 数据库的 I/O 操作的最小单位是页,InnoDB 数据页的默认大小是 16KB,意味着数据库每次读写都是以 16KB 为单位的

数据页结构

  • 数据页与数据页之间通过File Header指针连接,形成一个双向链表。物理上不连续但逻辑上连续。
    在这里插入图片描述

User Records 的结构

  • 数据页中的记录与记录是按照主键顺序组成单向链表,使得插入、删除方便。检索效率不高,于是数据页中有一个页目录起到快速检索的作用。
  • 数据页中的数据划分为几个组,每一个组对应一个槽。
  • 每个记录组的最后一条记录就是组内最大的记录,并且最后一条记录的头信息中会存储该组一共有多少条记录(粉丝的)
  • 页目录用来存储每组最后一条记录的地址偏移量(也叫做槽),每个槽相当于指针指向了不同组的最后一个记录。
  • 页目录就是由多个槽组成的,槽相当于分组记录的索引,我们通过槽查找记录时,定位到槽后,再遍历槽内的所有记录,找到对应的记录

在这里插入图片描述

B+ 树是如何进行查询的?

  • 当我们需要存储大量的记录时,就需要多个数据页,数据页与数据页通过指针相连接组成双向链表。由于一个数据页大小为16kb,而一次IO,一次性加载一个节点,每个节点都是一个数据页。从根节点进行查询,一层一层的查询由于B+Tree的只有叶子节点存放数据,因此当遍历到叶子节点后,就会找到相应的索引值,进而找到数据。
    在这里插入图片描述

B树、B+树、二叉树

二叉树

  • 每个节点只能有 2 个子节点,那么当节点个数越多的时候,树的高度也会相应变高,这样就会增加磁盘的 I/O 次数,从而影响数据查询的效率。

B 树

  • 每一个节点最多可以包括 M 个子节点。
  • B 树的每个节点都包含数据(索引+记录),而用户的记录数据的大小很有可能远远超过了索引数据,这就需要花费更多的磁盘 I/O 操作次数来读到「有用的索引数据」。
  • 使用 B 树来做范围查询的话,需要使用中序遍历,这会涉及多个节点的磁盘 I/O 问题,从而导致整体速度下降。

B+树

  • 叶子节点(最底部的节点)才会存放实际数据(索引+记录),非叶子节点只会存放索引;
  • 所有索引都会在叶子节点出现,叶子节点之间构成一个有序链表;
  • 非叶子节点的索引也会同时存在在子节点中,并且是在子节点中所有索引的最大(或最小)。
  • 非叶子节点中有多少个子节点,就有多少个索引;

在这里插入图片描述

MySQL 默认的存储引擎 InnoDB 采用的是 B+ 作为索引的数据结构的原因?

  • B+ 树的非叶子节点不存放实际的记录数据,仅存放索引,因此数据量相同的情况下,相比存储即存索引又存记录的 B 树,B+树的非叶子节点可以存放更多的索引,因此 B+ 树可以比 B 树更「矮胖」,查询底层节点的磁盘 I/O次数会更少。
  • B+ 树有大量的冗余节点(所有非叶子节点都是冗余索引),这些冗余索引让 B+ 树在插入、删除的效率都更高,比如删除根节点的时候,不会像 B 树那样会发生复杂的树的变化;
  • B+ 树叶子节点之间用链表连接了起来,有利于范围查询,而 B 树要实现范围查询,因此只能通过树的遍历来完成范围查询,这会涉及多个节点的磁盘 I/O 操作,范围查询效率不如 B+ 树。
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小呆鸟_coding

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值