阿里一面，给了几条SQL，问需要执行几次树搜索操作，复盘上次Redis缓存雪崩事故

为什么不使用哈希结构？

我们知道哈希结构，类似k-v结构，也就是，key和value是一对一关系。它用于等值查询还可以，但是范围查询它是无能为力的哦。

为什么不使用二叉树呢？

先回忆下二叉树相关知识啦~ 所谓二叉树，特点如下：

• 每个结点最多两个子树，分别称为左子树和右子树。
• 左子节点的值小于当前节点的值，当前节点值小于右子节点值
• 顶端的节点称为根节点，没有子节点的节点值称为叶子节点。

我们脑海中，很容易就浮现出这种二叉树结构图：

但是呢，有些特殊二叉树，它可能这样的哦：

如果二叉树特殊化为一个链表，相当于全表扫描。那么还要索引干嘛呀？因此，一般二叉树不适合作为索引结构。

为什么不使用平衡二叉树呢？

平衡二叉树特点：它也是一颗二叉查找树，任何节点的两个子树高度最大差为1。所以就不会出现特殊化一个链表的情况啦。

但是呢：

• 平衡二叉树插入或者更新是，需要左旋右旋维持平衡，维护代价大
• 如果数量多的话，树的高度会很高。因为数据是存在磁盘的，以它作为索引结构，每次从磁盘读取一个节点，操作IO的次数就多啦。

为什么不使用B树呢？

数据量大的话，平衡二叉树的高度会很高，会增加IO嘛。那为什么不选择同样数据量，高度更矮的B树呢？

B树相对于平衡二叉树，就可以存储更多的数据，高度更低。但是最后为甚选择B+树呢？因为B+树是B树的升级版：

• B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。
• B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。

四、面试官考点之一次B+树索引搜索过程

面试官： 假设有以下表结构，并且有这几条数据

CREATE TABLE employee (
id int(11) NOT NULL,
name varchar(255) DEFAULT NULL,
age int(11) DEFAULT NULL,
date datetime DEFAULT NULL,
sex int(1) DEFAULT NULL,
PRIMARY KEY (id),
KEY idx_age (age) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into employee values(100,‘小伦’,43,‘2021-01-20’,‘0’);
insert into employee values(200,‘俊杰’,48,‘2021-01-21’,‘0’);
insert into employee values(300,‘紫琪’,36,‘2020-01-21’,‘1’);
insert into employee values(400,‘立红’,32,‘2020-01-21’,‘0’);
insert into employee values(500,‘易迅’,37,‘2020-01-21’,‘1’);
insert into employee values(600,‘小军’,49,‘2021-01-21’,‘0’);
insert into employee values(700,‘小燕’,28,‘2021-01-21’,‘1’);

面试官： 如果执行以下的查询SQL，需要执行几次的树搜索操作？可以画下对应的索引结构图~

select * from Temployee where age=32;

解析： 其实这个，面试官就是考察候选人是否熟悉B+树索引结构图。可以像酱紫回答~

• 先画出idx_age索引的索引结构图，大概如下：

• 再画出id主键索引，我们先画出聚族索引结构图，如下：

因此，这条 SQL 查询语句执行大概流程就是酱紫：

• 1. 搜索idx_age索引树，将磁盘块1加载到内存，由于32<37,搜索左路分支，到磁盘寻址磁盘块2。
• 2. 将磁盘块2加载到内存中，在内存继续遍历，找到age=32的记录，取得id = 400.
• 3. 拿到id=400后，回到id主键索引树。
• 4. 搜索id主键索引树，将磁盘块1加载内存，在内存遍历，找到了400，但是B+树索引非叶子节点是不保存数据的。索引会继续搜索400的右分支，到磁盘寻址磁盘块3.
• 5. 将磁盘块3加载内存，在内存遍历，找到id=400的记录，拿到R4这一行的数据，好的，大功告成。

因此，这个SQL查询，执行了几次树的搜索操作，是不是一步了然了呀。特别的，在idx_age二级索引树找到主键id后，回到id主键索引搜索的过程,就称为回表。

什么是回表？拿到主键再回到主键索引查询的过程，就叫做回表

五、面试官考点之覆盖索引

面试官： 如果不用select *, 而是使用select id,age，以上的题目执行了几次树搜索操作呢？

解析： 这个问题，主要考察候选人的覆盖索引知识点。回到idx_age索引树，你可以发现查询选项id和age都在叶子节点上了。因此，可以直接提供查询结果啦，根本就不需要再回表了~

覆盖索引：在查询的数据列里面，不需要回表去查，直接从索引列就能取到想要的结果。换句话说，你SQL用到的索引列数据，覆盖了查询结果的列，就算上覆盖索引了。

所以，相对于上个问题，就是省去了回表的树搜索操作。

六、面试官考点之索引失效

面试官： 如果我现在给name字段加上普通索引，然后用个like模糊搜索，那会执行多少次查询呢？SQL如下：

select * from employee where name like ‘%杰伦%’;

解析： 这里考察的知识点就是，like是否会导致不走索引，看先该SQL的explain执行计划吧。其实like 模糊搜索，会导致不走索引的，如下:

因此，这条SQL最后就全表扫描啦~日常开发中，这几种骚操作都可能会导致索引失效，如下：

• 查询条件包含or，可能导致索引失效
• 如何字段类型是字符串，where时一定用引号括起来，否则索引失效
• like通配符可能导致索引失效。
• 联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
• 在索引列上使用mysql的内置函数，索引失效。
• 对索引列运算（如，+、-、*、/），索引失效。
• 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
• 索引字段上使用is null， is not null，可能导致索引失效。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

最后

为什么我不完全主张自学？
①平台上的大牛基本上都有很多年的工作经验了，你有没有想过之前行业的门槛是什么样的，现在行业门槛是什么样的？以前企业对于程序员能力要求没有这么高，甚至十多年前你只要会写个“Hello World”，你都可以入门这个行业，所以以前要入门是完全可以入门的。
②现在也有一些优秀的年轻大牛，他们或许也是自学成才，但是他们一定是具备优秀的学习能力，优秀的自我管理能力（时间管理，静心坚持等方面）以及善于发现问题并总结问题。
如果说你认为你的目标十分明确，能做到第②点所说的几个点，以目前的市场来看，你才真正的适合去自学。

除此之外，对于绝大部分人来说，报班一定是最好的一种快速成长的方式。但是有个问题，现在市场上的培训机构质量参差不齐，如果你没有找准一个好的培训班，完全是浪费精力，时间以及金钱，这个需要自己去甄别选择。

我个人建议线上比线下的性价比更高，线下培训价格基本上没2W是下不来的，线上教育现在比较成熟了，此次疫情期间，学生基本上都感受过线上的学习模式。相比线下而言，线上的优势以我的了解主要是以下几个方面：
①价格：线上的价格基本上是线下的一半；
②老师：相对而言线上教育的师资力量比线下更强大也更加丰富，资源更好协调；
③时间：学习时间相对而言更自由，不用裸辞学习，适合边学边工作，降低生活压力；
④课程：从课程内容来说，确实要比线下讲的更加深入。

应该学哪些技术才能达到企业的要求？（下图总结）

更自由，不用裸辞学习，适合边学边工作，降低生活压力；
④课程：从课程内容来说，确实要比线下讲的更加深入。

应该学哪些技术才能达到企业的要求？（下图总结）

[外链图片转存中…(img-z94UjNLH-1711197228482)]

[外链图片转存中…(img-EDkghpfg-1711197228482)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录