Mysql B+树学习

转自:https://juejin.im/post/59bf5cf65188252f92381fe5



概述


要描述清楚B+树,得先了解二叉查找数,平衡二叉树。


二叉查找树


这里写图片描述这里写图片描述

任意节点,它的左子树如果不为空,那么左子树上所有节点的值都小于根节点的值;
任意节点,他的右子树如果不为空,那么右子树上的所有节点的值大于根节点的值。

这个特性给查找带来了方便,如上图,要找key=3的键值,只要从5这个节点左子树进行递归查找即可,右子树的节点可以完全不理会。


平衡二叉树


二叉查找树有些缺陷,因为它对树的左右子树的高度没有任何限制,极端的情况下会出现如下图的类似链表的情况:

这里写图片描述这里写图片描述

这种二叉查找树对查询没任何好处的。所以有必要将树节点的左右子树的高度做一下限制,尽量保持平衡。

####二叉平衡树 图一

这里写图片描述这里写图片描述

####二叉查找树 图二

这里写图片描述这里写图片描述

二叉平衡树要求节点的左右子树的高度不要相差超过1,像图二中的6这个节点,它的左子树的高度是4,右子树的高度是2,相差超过了1,不具备平衡二叉树的特性。

由二叉平衡树的特性可以看到,查询的效率同样很高,同时又避免了二叉查找树出现链表那种极端情况。


B+树


####图三

这里写图片描述这里写图片描述

B+树有几个特点:
1、是多叉而不是二叉了,使用多叉的目的是降低树的高度;
2、每个节点不再只是存储一个key了,可以存储多个key;
3、非叶子节点存储key,叶子节点存储key和数据。
4、叶子节点两两相连,为顺序查询提供了帮助


Mysql为什么选择B+树


1、B+树的非叶子节点只是存储key,占用空间非常小,因此每一层的节点能索引到的数据范围更加的广。换句话说,每次IO操作可以观看更多的数据;

2、叶子节点两两相连,符合磁盘的预读特性。如图三中存储50和55的叶子节点,它有个指针指向了60和62这个叶子节点,那么当我们从磁盘读取50和55对应的数据的时候,由于磁盘的预读特性,会顺便把60和62对应的数据读取出来。这个时候属于顺序读取,而不是磁盘寻道了,加快了速度。

3、支持范围查询,而且部分范围查询非常高效,原因是数据都是存储在叶子节点这一层,并且有指针指向其他叶子节点,这样范围查询只需要遍历叶子节点这一层,无需整棵树遍历。


Mysql 索引简单描述


innodb存储引擎

自增主键索引

自增主键索引就是使用了B+数,索引文件同时也是数据文件,存储了整张表的数据。也就是说,平时我们执行sql按照主键查询的时候,那么只需要从这个索引文件获取数据即可。这种索引也叫聚集索引 ,原因是所有数据是按照主键聚集的。

辅助索引(非自增主键索引,也可以叫非聚集索引)

这种索引文件的叶子节点存储了键值和书签。键值说的就是列的值,书签就是对应记录的主键的值,如果按照某个辅助索引来查询数据的时候,如果没有用到覆盖索引,那么就得分两步走:
1、先从辅助索引文件中获取到数据对应的主键;
2、根据主键从聚集索引中获取真实数据。


MyISAM存储引擎

MyISAM引擎使用B+Tree作为索引结构,叶节点的data域存放的是数据记录的地址。这种称为非聚集索引,这个命名其实是对应上面innodb的叫法而已。


原文链接


Mysql B+树学习


<think>好的,我现在需要回答用户关于MySQL中B+索引机制、实现原理和数据结构的问题。首先,我需要回顾一下自己对B+的理解,确保基础概念正确。B+是一种平衡多路搜索,常用于数据库和文件系统中,因为它能有效减少磁盘I/O操作,提高查询效率。 接下来,我应该分步骤来组织回答。用户的问题涉及到机制、实现原理和数据结构,所以结构上可以分成几个部分:B+的结构特点、MySQL中B+索引的实现原理、应用场景,以及优化方法。这样结构清晰,用户容易理解。 首先,结构特点方面,要提到B+的层次结构,比如所有叶子节点形成有序链表,非叶子节点只存储键值用于导航,而数据都存储在叶子节点。同时,节点的大小通常设计为与磁盘页对齐,比如每个节点16KB,这样可以减少磁盘I/O次数。需要确认这些信息是否正确,比如MySQL的InnoDB存储引擎确实使用B+,并且每个页的大小默认是16KB[^2]。 然后是实现原理,需要解释B+MySQL中的具体应用,比如主键索引(聚集索引)和二级索引(非聚集索引)的区别。主键索引的叶子节点直接存储行数据,而二级索引存储主键值,这样查询时需要回表操作。这部分需要引用正确的资料,比如引用[2]提到InnoDB的主键索引和二级索引都是B+结构,二级索引的叶子节点存储主键值。 应用场景方面,应该包括范围查询的高效性、排序优化、联合索引的最左匹配原则等。例如,B+的有序叶子节点使得范围查询只需遍历链表,而不需要回溯到上层节点,这比B更高效。同时,联合索引遵循最左匹配,这也是B+结构决定的。需要确认这些是否正确,引用[2]中的优化部分可能提到减少磁盘I/O,而范围查询的高效性确实是B+的优点。 在优化方法方面,可以提到合理设计主键(比如自增主键避免页分裂)、避免过长的索引字段、覆盖索引减少回表等。这些优化点是否准确?比如,引用[2]中确实提到优化索引以减少磁盘I/O,覆盖索引可以避免二次查询[^2]。 需要注意是否正确区分B和B+的不同,比如B+非叶子节点不存储数据,所有数据在叶子节点,并且叶子节点有指针链接,这些结构上的差异导致B+更适合数据库索引。同时,需要确保引用的正确性,比如引用[1]提到B+用于高效存储和查询[^1],引用[3]提到哈希索引和自适应哈希索引,但用户的问题是关于B+,所以可能不需要深入讨论哈希索引,除非对比时提到[^3]。 在写作过程中,要确保所有数学表达式和公式使用正确的LaTeX格式,行内公式用$...$,独立公式用$$...$$。例如,节点存储的键值对数量公式可能需要用LaTeX排版,如$n$个键对应$n+1$个子节点指针。这部分需要检查是否正确应用了格式。 另外,用户要求生成相关问题,可能需要根据回答内容提出几个相关的问题,比如B+与B的区别、如何选择索引字段、页分裂的影响等。这些问题应该自然地从回答内容中延伸出来,帮助用户进一步学习。 最后,需要确保所有引用标记正确对应,比如引用[1]、[2]、[3]在回答中的位置是否准确,并且引用内容确实支持所述观点。例如,在讨论B+结构时引用[1][^1],在实现原理部分引用[2],在对比哈希索引时引用[3]。 总结下来,回答的结构应该是: 1. B+的结构特点 2. MySQL中的实现原理(主键索引和二级索引) 3. 应用场景与优势 4. 优化方法 5. 相关问题 需要确保每个部分的信息准确,引用正确,并且语言简洁明了,符合中文表达习惯。同时,检查是否有遗漏的关键点,比如B+的高度与查询效率的关系,或者具体例子说明查找过程,这些都能帮助用户更好地理解。</think>### MySQL中B+索引的实现原理与应用 #### 一、B+的结构特点 B+是一种多路平衡搜索,其核心设计目标是减少磁盘I/O次数,提升查询效率。其结构特点包括: 1. **分层导航**:非叶子节点仅存储键值(如主键或索引字段)和子节点指针,用于导航;叶子节点存储实际数据或数据地址,并通过双向链表串联,支持高效范围查询。 2. **节点容量优化**:每个节点大小通常与磁盘页对齐(如MySQL默认16KB),单个节点可存储更多键值,降低的高度。例如,若每个节点存储$n$个键,则的高度为$O(\log n)$,查询复杂度显著优于二叉。 3. **数据聚集性**:叶子节点按键值有序排列,且包含全部数据(主键索引)或主键引用(二级索引),避免跨层回溯。 #### 二、MySQL中B+索引的实现 1. **主键索引(聚集索引)** - 叶子节点直接存储行数据,物理存储按主键顺序组织。 - 若未显式定义主键,InnoDB会自动生成隐藏的6字节ROWID作为主键。 - 例如,查找主键为$k$的记录时,B+通过逐层比较定位到叶子节点,直接获取数据。 2. **二级索引(非聚集索引)** - 叶子节点存储索引字段值和对应主键值,查询需通过主键回表获取完整数据。 - 例如,对字段`age`建立索引,执行`SELECT * FROM users WHERE age=25`时: 1. 在`age`索引中定位到`age=25`的叶子节点,获取主键列表; 2. 根据主键回主键索引获取完整行数据。 3. **联合索引的最左匹配原则** 联合索引$(a,b,c)$的B+按$a$、$b$、$c$顺序排序。查询条件必须包含最左前缀(如`a=1 AND b=2`)才能利用索引,否则可能触发全表扫描。 #### 三、B+的优势与应用场景 1. **范围查询高效**:叶子节点的链表结构可直接遍历满足条件的范围,无需回溯上层节点。例如,`WHERE id BETWEEN 100 AND 200`只需定位起始点后顺序读取。 2. **排序与分组优化**:索引本身有序,可避免额外的排序操作。例如,`ORDER BY name`若`name`有索引,直接按B+顺序返回结果。 3. **减少磁盘I/O**:节点容量大、高低,多数查询只需2-3次磁盘访问(假设千万级数据,高为3-4层)。 #### 四、优化实践 1. **合理设计主键**:使用自增整数主键避免页分裂;避免过长主键(如UUID)导致节点存储效率下降。 2. **覆盖索引**:通过索引直接返回查询字段,避免回表。例如,若索引包含$(a,b)$,查询`SELECT a,b FROM table`可直接从索引获取数据。 3. **避免冗余索引**:联合索引$(a,b)$可替代单独索引$a$,减少存储和维护成本。 $$ \text{节点容量} = \frac{\text{磁盘页大小}}{\text{键值大小 + 指针大小}} $$ #### 引用 : B+的结构设计使其在范围查询和磁盘I/O优化上表现优异。 [^2]: InnoDB引擎通过B+索引实现主键与二级索引的分离存储,支持高效查询与事务处理。 : 哈希索引适用于等值查询,但B+在范围查询和排序场景更具优势。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值