Java岗大厂面试百日冲刺 - 日积月累，每日三题【Day28_b树是一种多路自平衡搜索树,它类似普通的二叉树,-CSDN博客

本文链接：https://blog.csdn.net/m0_60635084/article/details/119951165

我们可以通过这种方式来找到我们所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到相应页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式（无序）称为“非聚集索引”。

在这里插入图片描述

1、聚集索引

聚集索引是我们常用的一种索引，该索引中键值的逻辑顺序决定了表中相应行的物理顺序，我们叶子结点直接对应的实际数据，当索引值唯一（unique）时，使用聚集索引查找特定的行效率很高。例如，使用唯一店员 ID 列 emp_id 查找特定雇员的最快速的方法，是在 emp_id 列上创建聚集索引或 PRIMARY KEY 约束。可见，自增主键就是一个标准的聚集索引。

当某列满足两个条件时，我们可以创建聚集索引：

数据存储有序（如自增）
key值应当唯一

聚簇索引像字典，字典按字母顺序排列数据，有序。在聚集索引中，索引包含指向数据存储的块而不是数据存储地址的指针，和非聚集索引（Normal）相反。

在这里插入图片描述

2、非聚集索引

非聚集索引就是索引类型为Normal的普通索引啦，我们在《聊聊MySQL索引“B+Tree”的前世今生》这篇文章中提到，B+Tree（这里是索引类型是Normal）所有关键字存储在叶子节点，但不存储真正的data，叶子结点存的是一个指向磁盘data的指针，需要到磁盘数据页中取。

非聚集索引的数据存储在一个位置，索引存储在另一位置。由于数据和非聚集索引是分开存储的，因此在一个表中可以有多个非聚集索引。

聚集索引和非聚集索引的区别：

单表中只能有一个聚集索引，而非聚集索引单表可以存在多个。
聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
聚集索引：物理存储按照索引排序；非聚集索引：物理存储不按照索引排序；

追问1：为什么聚集索引可以创建在任何一列上，如果此表没有主键约束，即有可能存在重复行数据呢？

乍一看，这还真是和聚集索引的约束相背，但实际情况真可以创建聚集索引。

其原因是：如果未使用 UNIQUE 属性创建聚集索引，数据库引擎将向表自动添加一个四字节 uniqueifier列。必要时，数据库引擎将向行自动添加一个 uniqueifier 值，使每个键唯一。此列和列值供内部使用，用户不能查看或访问。

追问2：聚集索引一定比非聚集索引性能优么？

如果想查询学分在60-90之间的学生的学分以及姓名，在学分上创建聚集索引是否是最优的呢？

并不是。既然只输出两列，我们可以在学分以及学生姓名上创建联合非聚集索引，此时的索引就形成了覆盖索引，即索引所存储的内容就是最终输出的数据，这种索引当然比以学分为聚集索引做查询性能好，算是相当于联合聚集索引~~灵活运用即可。

在这里插入图片描述

陈小哈，一个爱睡懒觉的崽子。工作日的它却总爱发呆~

面试题2：说一说你对 B树和 B+树的理解吧

=======================================================================================

1、B树（Balanced Tree）多路平衡查找树多叉

B树是一种多路自平衡搜索树，它类似普通的二叉树，但是B书允许每个节点有更多的子节点。B树示意图如下：值得注意的是，B树的非叶子节点和叶子结点的data数据都是分开存储的，那么针对范围查询、排序等常用特性就很不友好了。

在这里插入图片描述

B树的特点：

所有键值分布在整个树中
任何关键字出现且只出现在一个节点中
搜索有可能在非叶子节点结束
在关键字全集内做一次查找，性能逼近二分查找算法

为了提升效率，要尽量减少磁盘I/O的次数。实际过程中，磁盘并不是每次严格按需读取，而是每次都会预读。

磁盘读取完需要的数据后，会按顺序再多读一部分数据到内存中，这样做的理论依据是计算机科学中注明的局部性原理：

由于磁盘顺序读取的效率很高(不需要寻址时间，只需很少的旋转时间)，因此对于具有局部性的程序来说，预读可以提高I/O效率.预读的长度一般为页(page)的整倍数。
MySQL(默认使用InnoDB引擎)，将记录按照页的方式进行管理，每页大小默认为16K(可以修改)。

B-Tree借助计算机磁盘预读机制:

每次新建节点的时候，都是申请一个页的空间，所以每查找一个节点只需要一次I/O;因为实际应用当中，节点深度会很少，所以查找效率很高.

2、B+ Tree (B+树是B树的变体，也是一种多路搜索树)

在这里插入图片描述

从图中也可以看到，B+树与B树的不同在于：

所有关键字存储在叶子节点，非叶子节点不存储真正的data，从而可以快速定位到叶子结点。
为所有叶子节点增加了一个链指针，意味着所有的值都是按顺序存储的，并且每一个叶子页到根的距离相同，很适合查找范围数据。说明支持范围查询和天然排序。

因此，B+Tree可以对<，<=，=，>，>=，BETWEEN，IN，以及不以通配符开始的LIKE使用索引。且如果用到了该索引，排序功能的消耗大大减少。

B+树的优点：

比较的次数均衡，减少了I/O次数，提高了查找速度，查找也更稳定。

B+树的磁盘读写代价更低
B+树的查询效率更加稳定

要知道的是，你每次创建表，系统会为你自动创建一个基于ID的聚集索引（上述B+树），存储全部数据；你每次增加索引，数据库就会为你创建一个附加索引（上述B+树），索引选取的字段个数就是每个节点存储数据索引的个数，注意该索引并不存储全部数据。

在这里插入图片描述

课间休息，又来秀一下来自咱们群里同学的搬砖工地，坐标：深圳。

作者：晓海wiley

面试题3：说一下你对最左前缀原则的理解吧

===================================================================================

通常我们在建立联合索引的时候，相信建立过索引的同学们会发现，无论是Oracle还是 MySQL 都会让我们选择索引的顺序，比如我们想在a,b,c三个字段上建立一个联合索引，我们可以选择自己想要的优先级，(a、b、c)，或是 (b、a、c) 或者是(c、a、b) 等顺序。

在这里插入图片描述

为什么数据库会让我们选择字段的顺序呢？不都是三个字段的联合索引么？这里就引出了数据库索引的最重要的原则之一，最左匹配原则。

在我们开发中经常会遇到这种问题，明明这个字段建了联合索引，但是SQL查询该字段时却不会使用这个索引。难道这索引是假的？白嫖老子资源？！

比如索引abc_index:(a,b,c)是a,b,c三个字段的联合索引，下列sql执行时都无法命中索引abc_index；


select * from table where c = '1';



select * from table where b ='1' and c ='2';

以下三种情况却会走索引:


select * from table where a = '1';



select * from table where a = '1' and b = '2';



select * from table where a = '1' and b = '2'  and c='3';

从上面两个例子大家有木有看出点眉目呢？

是的，索引abc_index:(a,b,c)，只会在where条件中带有(a)、(a,b)、(a,b,c)的三种类型的查询中使用。其实这里说的有一点歧义，其实当where条件只有(a,c)时也会走，但是只走a字段索引，不会走c字段。

那么这都是为什么呢？我们一起来看看其原理吧。

一、最左匹配原则的原理

MySQL 建立多列索引（联合索引）有最左匹配的原则，即最左优先：

如果有一个 2 列的索引 (a, b)，则已经对 (a)、(a, b) 上建立了索引；

如果有一个 3 列索引 (a, b, c)，则已经对 (a)、(a, b)、(a, b, c) 上建立了索引；

假设数据表 LOL (id,sex,price,name) 的物理位置（表中的无序数据）如下：

（注：下面数据是测试少量数据选用的，只为了方便大家看清楚。实际操作中，应按照使用频率、数据区分度来综合设定索引顺序~）


主键id  sex(a)   price(b)      name(c)    

(1)     1         1350         AAA安妮

(2)     2         6300         MMM盲僧

(3)     1         3150         NNN奈德丽

(4)     2         6300         CCC锤石

(5)     1         6300         LLL龙女

(6)     2         3150         EEE伊泽瑞尔

(7)     2         6300         III艾克

(8)     1         6300         BBB暴走萝莉

(9)     1         4800         FFF发条魔灵

(10)    2         3150         KKK卡牌大师

(11)    1         450          HHH寒冰射手

(12)    2         450          GGG盖伦

(13)    2         3150         OOO小提莫

(14)    2         3150         DDD刀锋之影

(15)    2         6300         JJJ疾风剑豪

(16)    2         450          JJJ剑圣

当你在LOL表创建一个联合索引 abc_index:(sex,price,name)时，生成的索引文件逻辑上等同于下表内容（分级排序）：


sex(a)   price(b)       name(c)         主键id

1        450            HHH寒冰射手      (11)

1        1350           AAA安妮          (1)

1        3150           NNN奈德丽        (3)

1        4800           FFF发条魔灵       (9)

1        6300           BBB暴走萝莉       (8)

1        6300           LLL龙女          (5)

2        450            GGG盖伦          (12)

2        450            JJJ剑圣          (16)

2        3150           DDD刀锋之影       (14)

2        3150           EEE伊泽瑞尔       (6)

2        3150           KKK卡牌大师       (10)

2        3150           OOO小提莫         (13)

2        6300           CCC锤石          (4)

2        6300           III艾克          (7)

2        6300           JJJ疾风剑豪       (15)

2        6300           MMM盲僧          (2)

小伙伴儿们有没有发现B+树联合索引的规律？感觉还有点模糊的话，那咱们再来看一张索引存储数据的结构图，或许更明了一些。

在这里插入图片描述