MySQL的B+Tree索引到底是咋回事?聚簇索引到底是如何长高的?

你肯定知道MySQL进行CRUD是在内存中进行的,也就是在Buffer Pool中。然后你也知道了当内存中没有MySQL需要的数据时,MySQL会从Disk中通过IO操作将数据读入内存中。读取的单位呢就是:数据页

一般数据页长下面这样

没错,数据页中存储着真实的数据,而且数据页在内存中是以双向联表的方式组织起来的!如下图

而在B+Tree的设定中,它要求主键索引时递增的,也就是说如果主键索引时递增的话,那么就要求右侧的数据页中的所有数据均比左侧数据页中的数据大。但是很明显上图并不符合,因此需要通过页分裂来调整成下面这样。

好,现在你回想一下,之前你肯定有听说过:MySQL的B+Tree聚簇索引,只有叶子节点才存储真实的数据,而非叶子节点中存储的是索引数据,而且叶子节点之间是通过双向链表连接起来

没错,那所有的B+Tree的叶子节点就是上图中的数据页,并且它们确实是通过双向链表关联起来的!

我们接着往下看,如果只看上图由数据页连接起来的双向链表的话,这时如果我们检索id=7的数据行,那会发生什么?

很明显我们要从头开始扫描!

那你可能会问:方才不是说B+Tree要求主键是递增的嘛?并且有页分裂机制保证右边的数据页中的所有数据均比它左边的数据页的索引值大。那进行二分查找不行嘛?

答:是的,确实可以在单个数据页中进行二分查找,但是数据页之间的组织关系是链表呀,所以从头开始遍历是避免不了的。

那MySQL怎么办的呢?

如下图:MySQL针对诸多的数据页抽象出了一个索引目录

那有了这个索引目录我们再在诸多的数据页中检索时看起来就容易多了!直接就拥有了二分检索的能力!

而且这个所以目录其实也是存在于数据页中的,不同于叶子节点的是,它里面只是存储了索引信息,而叶子节点中存储的是真实数据?

而索引页的诞生也就意味着B+Tree的雏形已经诞生了!

随着用户不断的select,buffer pool中的数据页的越来越多,那么索引页中的数据也会水涨船高。当现有的索引体量超过16KB(一个数据页的容量)时就不得不搞一个新的索引页来存储新的索引信息。这时这颗B+Tree就会慢慢变得越来越胖。

那你也知道B+Tree是B树的变种,而B树其实可以是2-3树、2-3-4数....等等M阶树的泛称,当每个节点中能存储的元素达到上限后,树就会长高 。

就像下图这样:

原文链接:
https://www.cnblogs.com/ZhuChangwu/p/14807772.html

全部评论

相关推荐

想干测开的tomca...:让我来压力你!!!: 这份简历看着“技术词堆得满”,实则是“虚胖没干货”,槽点一抓一大把: 1. **项目描述是“技术名词报菜名”,没半分自己的实际价值** 不管是IntelliDoc还是人人探店,全是堆Redis、Elasticsearch、RAG这些时髦词,但你到底干了啥?“基于Redis Bitmap管理分片”是你写了核心逻辑还是只调用了API?“QPS提升至1500”是你独立压测优化的,还是团队成果你蹭着写?全程没“我负责XX模块”“解决了XX具体问题”,纯把技术文档里的术语扒下来凑字数,看着像“知道名词但没实际动手”的实习生抄的。 2. **短项目塞满超纲技术点,可信度直接***** IntelliDoc就干了5个月,又是RAG又是大模型流式响应又是RBAC权限,这堆活儿正经团队分工干都得小半年,你一个后端开发5个月能吃透这么多?明显是把能想到的技术全往里面塞,生怕别人知道你实际只做了个文件上传——这种“技术堆砌式造假”,面试官一眼就能看出水分。 3. **技能栏是“模糊词混子集合”,没半点硬核度** “熟悉HashMap底层”“了解JVM内存模型”——“熟悉”是能手写扩容逻辑?“了解”是能排查GC问题?全是模棱两可的词,既没对应项目里的实践,也没体现深度,等于白写;项目里用了Elasticsearch的KNN检索,技能栏里提都没提具体掌握程度,明显是“用过但不懂”的硬凑。 4. **教育背景和自我评价全是“无效信息垃圾”** GPA前10%这么好的牌,只列“Java程序设计”这种基础课,分布式、微服务这些后端核心课提都不提,白瞎了专业优势;自我评价那堆“积极认真、细心负责”,是从招聘网站抄的模板吧?没有任何和项目挂钩的具体事例,比如“解决过XX bug”“优化过XX性能”,纯废话,看完等于没看。 总结:这简历是“技术名词缝合怪+自我感动式凑数”,看着像“背了后端技术栈名词的应届生”,实则没干货、没重点、没可信度——面试官扫30秒就会丢一边,因为连“你能干嘛”都没说清楚。
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务