1. 图片分析法
- 1.1阶的概念
阶的概念:假设是3阶B+树,单个节点最多可以有2个元素,单节点下,最多可以有3个孩子(分支)
- 1.2.阶的计算公式
查看MySQL单次加载磁盘io的大小
SHOW GLOBAL STATUS LIKE '%Innodb_page_size%';
场景:针对B+树的非叶子节点
MySQL单次加载磁盘io的大小=16kb
公式:16k/元素的大小=树的阶
那么在相同的元素个数情况下,
B树的单个元素比B+树大,B 树的阶就越低,树就越高,查询性能就低!
说白了就跟树高有关!
2. 原理思考法
众所周知,Hash比B+树快,那为什么还要用B+树?
为什么非得要保证它的平衡性???
树越矮胖,阶越高,查询效率就越高
说说B树?
为什么要设计成多路?
问题就是没考虑程序运行的内存,我们的索引是磁盘上的,假设数据量很大,是无法加载到内存的
B树用在那里?
要知道,文件系统和数据库的索引都是存在硬盘上的,并且如果数据量大的话,不一定能一次性加载到内存中。要考虑内存情况差点挂了
B+树?
这也是和业务场景相关的,你想想,数据库中select数据,不一定只选一条,很多时候会选多条,比如按照id排序后选10条。
最终答案:如果是多条的话,B树需要做局部的中序遍历,可能要跨层访问。而B+树由于所有数据都在叶子结点,不用跨层,同时由于有链表结构,只需要找到首尾,通过链表就能把所有数据取出来了。
【回到开头现场】
这和业务场景有关。如果只选一个数据,那确实是hash更快。但是数据库中经常会选择多条,这时候由于B+树索引有序,并且又有链表相连,它的查询效率比hash就快很多了。
而且数据库中的索引一般是在磁盘上,数据量大的情况可能无法一次装入内存,B+树的设计可以允许数据分批加载,同时树的高度较低,提高查找效率。
欢迎小伙伴们点赞转发.