MySQL索引由浅入深！万字长文详解MySQL

最新推荐文章于 2024-07-11 21:41:59 发布

2301_79055107

最新推荐文章于 2024-07-11 21:41:59 发布

阅读量323

点赞数 4

分类专栏：程序员文章标签： mysql 数据库

本文链接：https://blog.csdn.net/2301_79055107/article/details/137826901

版权

程序员专栏收录该内容

557 篇文章 1 订阅

订阅专栏

例如左子树的深度是 2，右子树的深度只能是 1 或者 3。这个时候我们再按顺序插入 2,3,4,6,7,8，就不会“叉劈”

AVL树的平衡是怎么做到的呢？主要用到了两个操作左旋、右旋。

插入 1、2、3。当我们插入了 1、2 之后，如果按照二叉查找树的定义，3 肯定是要在 2 的右边的，这个时候根节点 1 的右节点深度会变成 2，但是左节点的深度是 0，因为它没有子节点，所以就会违反平衡二叉树的定义。那应该怎么办呢?因为它是右节点下面接一个右节点，右–右型，所以这个时候我们要把 2 提上去，这个操作叫做左旋。

同样的，如果我们插入3、2、1，这个时候会变成左左型，就会发生右旋操作，把 2提上去。

既然平衡二叉树能保持平衡，不会退化，那么我们用平衡二叉树存储索引可以吗？——可以的。

当我们用树的结构来存储索引的时候，访问一个节点就要跟磁盘之间发生一次 IO。 InnoDB 操作磁盘的最小的单位是一页(或者叫一个磁盘块)。与主存不同，磁盘I/O存在机械运动耗费，因此磁盘I/O的时间消耗是巨大的。

所以如果每个节点存储的数据太少，从索引中找到我们需要的数据，就要访问更多的节点，意味着跟磁盘交互次数就会过多。

那么解决方案是什么？

让每个节点存储更多的数据。
让节点上有更多的关键字。

节点上的关键字的数量越多，我们的指针数也越多，也就是意味着可以有更多的分叉(我们把它叫做“路数”)。

因为分叉数越多，树的深度就会减少(根节点是 0)。这样，树就从瘦高变成了矮胖。

这个时候，我们的树就不再是二叉了，而是多叉，或者叫做多路。

6、多路平衡查找树（B-Tree）

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

接下来看一下多路平衡查找树，也就是B树。

B树是一种多叉平衡查找树，如下图主要特点：

B树的节点中存储着多个元素，每个内节点有多个分叉。
节点中的元素包含键值和数据，节点中的键值从大到小排列。也就是说，在所有的节点都储存数据。
父节点当中的元素不会出现在子节点中。
所有的叶子结点都位于同一层，叶节点具有相同的深度，叶节点之间没有指针连接。

以上图为例，我们来简单看几个查询：

如果查找key<17，就走左边子节点；
如果查找17<key<35，就走中间子节点；
如果查找key>35，就走右边子节点；
如果查找key=17，直接命中；
如果查找key=35，直接命中；

B树看起来很完美，到这就结束了吗？并没有。

B树不支持范围查询的快速查找，你想想这么一个情况如果我们想要查找10和35之间的数据，查找到15之后，需要回到根节点重新遍历查找，需要从根节点进行多次遍历，查询效率有待提高。

如果data存储的是行记录，行的大小随着列数的增多，所占空间会变大。这时，一个页中可存储的数据量就会变少，树相应就会变高，磁盘IO次数就会变大

所以接下来就引入我们的终极数据结构——B+树。

7、加强版多路平衡查找树(B+Tree)

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

B+树，作为B树的升级版，在B树基础上，MySQL在B树的基础上继续改造，使用B+树构建索引。B+树和B树最主要的区别在于非叶子节点是否存储数据的问题

B树：非叶子节点和叶子节点都会存储数据。B+树：只有叶子节点才会存储数据，非叶子节点只存储键值。叶子节点之间使用双向指针连接，最底层的叶子节点形成了一个双向有序链表。

来看一下InnoDB里的B+树的具体存储结构：

来说一下这张图的重点：

最外面的方块，地块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（粉色所示）和指针（黄色/灰色所示），如根节点磁盘包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、4、5……、65。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。
叶子节点之间使用双向指针连接，最底层的叶子节点形成了一个双向有序链表。

7.1、存储容量

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

举个例子:假设一条记录是 1K，一个叶子节点(一页)可以存储 16 条记录。非叶子节点可以存储多少个指针?

假设索引字段是 bigint 类型，长度为 8 字节。指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节。非叶子节点(一页)可以存储 16384/14=1170 个这样的单元(键值+指针)，代表有 1170 个指针。

树深度为 2 的时候，有 1170^2 个叶子节点，可以存储的数据为 1170*1170*16=21902400。

在查找数据时一次页的查找代表一次 IO，也就是说，一张 2000 万左右的表，查询数据最多需要访问 3 次磁盘。

所以在 InnoDB 中 B+ 树深度一般为 1-3 层，它就能满足千万级的数据存储。

7.2、查询效率

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

我们来看一下 B+Tree 的数据搜寻过程:

例如我们要查找 35，在根节点就找到了键值，但是因为它不是页子节点，所以会继续往下搜寻，25 是[17,35)的左闭右开的区间的临界值，所以会走中间的子节点，然后继续搜索，它又是[28,34)的左闭右开的区间的临界值，所以会走左边的子节点，最后在叶子节点上找到了需要的数据。
如果是范围查询，比如要查询从 22 到 60 的数据，当找到 22 之后，只需要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高了区间查询效率(不需要返回上层父节点重复遍历查找)。
3）添加了指向相邻叶节点的指针**，形成了带有顺序访问指针的B+Tree，这样做是为了**提高区间查找的效率，只要找到第一个值那么就可以顺序的查找后面的值。

7.3、B+树特点总结

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

总结一下，InnoDB 中的 B+Tree 的特点:

它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。B Tree 解决的两大问题是什么?(每个节点存储更多关键字；路数更多)
2)扫库、扫表能力更强(如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵 B+Tree 拿到所有的数据)
B+Tree 的磁盘读写能力相对于 B Tree 来说更强(根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多)
排序能力更强(因为叶子节点上有下一个数据区的指针，数据形成了链表)
效率更加稳定(B+Tree 永远是在叶子节点拿到数据，所以 IO 次数是稳定的)

三、聚簇索引和非聚簇索引

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

MySQL中最常见的两种存储引擎分别是MyISAM和InnoDB，分别实现了非聚簇索引和聚簇索引。

首先要介绍几个概念，在索引的分类中，我们可以按照索引的键是否为主键来分为“主键索引”和“辅助索引”，使用主键键值建立的索引称为“主键索引”，其它的称为“辅助索引”。因此主键索引只能有一个，辅助索引可以有很多个。

1、MyISAM——非聚簇索引

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

MyISAM存储引擎采用的是非聚簇索引，非聚簇索引的主键索引和辅助索引基本上是相同的，只是主键索引不允许重复，不允许空值，他们的叶子结点的key都存储指向键值对应的数据的物理地址。

非聚簇索引的数据表和索引表是分开存储的。

非聚簇索引中的数据是根据数据的插入顺序保存。因此非聚簇索引更适合单个数据的查询。插入顺序不受键值影响。

思考：既然非聚簇索引的主键索引索引和辅助索引指向相同的内容，为什么还要辅助索引呢？索引不就是用来查询的吗，用在哪些地方呢？不就是WHERE和ORDER BY 语句后面吗，那么如果查询的条件不是主键怎么办呢，这个时候就需要辅助索引了。

2、InnoDB——聚簇索引

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

聚簇索引的主键索引的叶子结点存储的是键值对应的数据本身，辅助索引的叶子结点存储的是键值对应的数据的主键键值。因此主键的值长度越小越好，类型越简单越好。

聚簇索引的数据和主键索引存储在一起。

从上图中可以看到辅助索引的叶子节点的data存储的是主键的值，主键索引的叶子节点的data存储的是数据本身，也就是说数据和索引存储在一起，并且索引查询到的地方就是数据（data）本身，那么索引的顺序和数据本身的顺序就是相同的。

因为聚簇辅助索引存储的是主键的键值，因此可以在数据行移动或者页分裂的时候降低成本，因为这时不用维护辅助索引。但是由于主键索引存储的是数据本身，因此聚簇索引会占用更多的空间。

聚簇索引在插入新数据的时候比非聚簇索引慢很多，因为插入新数据时需要检测主键是否重复，这需要遍历主索引的所有叶节点，而非聚簇索引的叶节点保存的是数据地址，占用空间少，因此分布集中，查询的时候I/O更少，但聚簇索引的主索引中存储的是数据本身，数据占用空间大，分布范围更大，可能占用好多的扇区，因此需要更多次I/O才能遍历完毕。

四、索引使用原则

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

1、列的离散度

===========

第一个叫做列的离散度，我们先来看一下列的离散度的公式:

count(distinct(column_name)) : count(*)

列的全部不同值和所有数据行的比例。数据行数相同的情况下，分子越大，列的离散度就越高。

mysql> SELECT * FROM test.user ORDER BY id LIMIT 10 OFFSET 0;

±—±----------±-------±------------+

±—±----------±-------±------------+

| 1 | 秦啭 | 0 | 13601722591 |

| 2 | 李镒榘 | 0 | 15204160836 |

| 3 | 陈艮 | 0 | 13601994087 |

| 4 | 沈夷旌 | 0 | 15507785988 |

| 5 | 朱桐泰 | 1 | 13201268193 |

| 6 | 周韬蕊 | 1 | 15705478612 |

| 7 | 冯叻加 | 0 | 13705834063 |

| 8 | 王焓 | 1 | 15006956358 |

| 9 | 黄芪 | 0 | 15108012536 |

| 10 | 吴笄游 | 0 | 15301860708 |

±—±----------±-------±------------+

10 rows in set (0.00 sec)

简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。

了解了离散度的概念之后，我们再来思考一个问题，我们在 name 上面建立索引和在 gender 上面建立索引有什么区别。

当我们用在 gender 上建立的索引去检索数据的时候，由于重复值太多，需要扫描的行数就更多。例如，我们现在在 gender 列上面创建一个索引，然后看一下执行计划。

ALTER TABLE user ADD INDEX idx_user_gender (gender); – 耗时比较久

EXPLAIN SELECT * FROM user WHERE gender = 0;

±—±------------±------------±-----------±-----±----------------±----------------±--------±------±--------±---------±------+

±—±------------±------------±-----------±-----±----------------±----------------±--------±------±--------±---------±------+

| 1 | SIMPLE | user | NULL | ref | idx_user_gender | idx_user_gender | 2 | const | 2492574 | 100.00 | NULL |

±—±------------±------------±-----------±-----±----------------±----------------±--------±------±--------±---------±------+

1 row in set, 1 warning (0.00 sec)

而 name 的离散度更高，比如“陈艮”的这名字，只需要扫描一行。

ALTER TABLE user ADD INDEX idx_user_name (name);

EXPLAIN SELECT * FROM user WHERE name = ‘陈艮’;

±—±------------±------------±-----------±-----±---------------------------±---------±--------±------±-----±---------±------+

±—±------------±------------±-----------±-----±---------------------------±---------±--------±------±-----±---------±------+

| 1 | SIMPLE | user | NULL | ref | idx_name | idx_name | 1023 | const | 1 | 100.00 | NULL |

±—±------------±------------±-----------±-----±---------------------------±---------±--------±------±-----±---------±------+

1 row in set, 1 warning (0.00 sec)

查看表上的索引，Cardinality [kɑ:dɪ’nælɪtɪ]代表基数，代表预估的不重复的值的数量。索引的基数与表总行数越接近，列的离散度就越高。

mysql> show indexes from user;

±------------±-----------±------------------±-------------±------------±----------±------------±---------±-------±-----±-----------±--------±--------------+

±------------±-----------±------------------±-------------±------------±----------±------------±---------±-------±-----±-----------±--------±--------------+

| user | 0 | PRIMARY | 1 | id | A | 4985145 | NULL | NULL | | BTREE | | |

| user | 1 | idx_name | 1 | name | A | 2605146 | NULL | NULL | YES | BTREE | | |

| user | 1 | idx_user_gender | 1 | gender | A | 1 | NULL | NULL | YES | BTREE | | |

| user | 1 | comidx_name_phone | 1 | name | A | 2595718 | NULL | NULL | YES | BTREE | | |

| user | 1 | comidx_name_phone | 2 | phone | A | 4972647 | NULL | NULL | YES | BTREE | | |

±------------±-----------±------------------±-------------±------------±----------±------------±---------±-------±-----±-----------±--------±--------------+

5 rows in set (0.00 sec)

如果在索引 B+Tree 结构里面的重复值太多，MySQL 的优化器发现走索引跟使用全表扫描差不了多少的时候，就算建了索引，也不一定会走索引。

2、组合索引最左匹配

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

前面我们说的都是针对单列创建的索引，但有的时候我们的多条件查询的时候，也会建立组合索引。单列索引可以看成是特殊的组合索引。

比如我们在 user 表上面，给 name 和 phone 建立了一个组合索引。

ALTER TABLE user add INDEX comidx_name_phone (name,phone);

组合索引在 B+Tree 中是复合的数据结构，它是按照从左到右的顺序来建立搜索树的 (name 在左边，phone 在右边)。

从这张图可以看出来，name 是有序的，phone 是无序的。当 name 相等的时候， phone 才是有序的。

这个时候我们使用 where name= ‘wangwu‘ and phone = ‘139xx ‘去查询数据的时候， B+Tree 会优先比较 name 来确定下一步应该搜索的方向，往左还是往右。如果 name 相同的时候再比较 phone。但是如果查询条件没有 name，就不知道第一步应该查哪个节点，因为建立搜索树的时候 name 是第一个比较因子，所以用不到索引。

2.1、什么时候用到组合索引

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

所以，我们在建立组合索引的时候，一定要把最常用的列放在最左边。比如下面的三条语句，能用到组合索引吗?

1)使用两个字段，可以用到组合索引:

mysql> EXPLAIN SELECT * FROM user WHERE name= ‘陈艮’ AND phone = ‘13601994087’;

±—±------------±------------±-----------±-----±---------------------------±------------------±--------±------------±-----±---------±------+

±—±------------±------------±-----------±-----±---------------------------±------------------±--------±------------±-----±---------±------+

| 1 | SIMPLE | user_innodb | NULL | ref | comidx_name_phone | comidx_name_phone | 1070 | const,const | 1 | 100.00 | NULL |

±—±------------±------------±-----------±-----±---------------------------±------------------±--------±------------±-----±---------±------+

1 row in set, 1 warning (0.00 sec)

2)使用左边的 name 字段，可以用到组合索引:

mysql> EXPLAIN SELECT * FROM user WHERE name= ‘陈艮’;

±—±------------±------------±-----------±-----±---------------------------±---------±--------±------±-----±---------±------+

±—±------------±------------±-----------±-----±---------------------------±---------±--------±------±-----±---------±------+

| 1 | SIMPLE | user_innodb | NULL | ref | comidx_name_phone | idx_name | 1023 | const | 19 | 100.00 | NULL |

±—±------------±------------±-----------±-----±---------------------------±---------±--------±------±-----±---------±------+

1 row in set, 1 warning (0.00 sec)

3)使用右边的 phone 字段，无法使用索引，全表扫描:

mysql> EXPLAIN SELECT * FROM user WHERE phone = ‘13601994087’;

±—±------------±------------±-----------±-----±--------------±-----±--------±-----±--------±---------±------------+

±—±------------±------------±-----------±-----±--------------±-----±--------±-----±--------±---------±------------+

±—±------------±------------±-----------±-----±--------------±-----±--------±-----±--------±---------±------------+

1 row in set, 1 warning (0.00 sec)

2.2、如何创建组合索引

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

当创建(a,b,c)联合索引时，相当于创建了(a)单列索引，(a,b)组合索引以及(a,b,c)组合索引，想要索引生效的话,只能使用 a和a,b和a,b,c三种组合；当然，b,a也是好使的，因为sql会对它优化。

用 where b=? 和 where b=? and c=? 和 where a=? and c=?是不能使用到索引。不能不用第一个字段，不能中断。

这里就是 MySQL 组合索引的最左匹配原则。

3、覆盖索引

==========

3.1、回表

==========

在聚簇索引里，通过辅助索引查找数据，先通过索引找到主键索引的键值，再通过主键值查出索引里面没有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程就叫回表。

例如:select * from user where name = ‘lisi’;

3.2、覆盖索引

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

在辅助索引里面，不管是单列索引还是联合索引，如果 select 的数据列只用从索引中就能够取得，不必从数据区中读取，这时候使用的索引就叫做覆盖索引，这样就避免了回表。

我们先来创建一个联合索引:

– 创建联合索引

ALTER TABLE user add INDEX ‘comixd_name_phone’ (‘name’,‘phone’);

这三个查询语句都用到了覆盖索引:

EXPLAIN SELECT name,phone FROM user WHERE name= ‘陈艮’ AND phone = ‘13601994087’;

EXPLAIN SELECT name FROM user WHERE name= ‘陈艮’ AND phone = ‘13601994087’;

EXPLAIN SELECT phone FROM user WHERE name= ‘陈艮’ AND phone = ‘13601994087’;

Extra 里面值为“Using index”代表使用了覆盖索引。

mysql> EXPLAIN SELECT name FROM user_innodb WHERE name= ‘陈艮’ AND phone = ‘13601994087’;

±—±------------±------------±-----------±-----±---------------------------±------------------±--------±------------±-----±---------±------------+

±—±------------±------------±-----------±-----±---------------------------±------------------±--------±------------±-----±---------±------------+

| 1 | SIMPLE | user_innodb | NULL | ref | idx_name,comidx_name_phone | comidx_name_phone | 1070 | const,const | 1 | 100.00 | Using index |

±—±------------±------------±-----------±-----±---------------------------±------------------±--------±------------±-----±---------±------------+

1 row in set, 1 warning (0.00 sec)

select * ，用不到覆盖索引。

很明显，因为覆盖索引减少了 IO 次数，减少了数据的访问量，可以大大地提升查询效率。

4、索引条件下推(ICP)

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

“索引条件下推”，称为 Index Condition Pushdown (ICP)，这是MySQL提供的用某一个索引对一个特定的表从表中获取元组”，注意我们这里特意强调了“一个”，这是因为这样的索引优化不是用于多表连接而是用于单表扫描，确切地说，是单表利用索引进行扫描以获取数据的一种方式。它的作用如下

一是说明减少完整记录（一条完整元组）读取的个数；
二是说明对于InnoDB聚集索引无效，只能是对SECOND INDEX这样的非聚簇索引有效。

关闭 ICP:

set optimizer_switch=‘index_condition_pushdown=off’;

查看参数:

show variables like ‘optimizer_switch’;

现在我们要查询所有名字为陈艮，并且手机号码后四位为4087这个人。查询的 SQL:

SELECT * FROM user WHERE name= ‘陈艮’ and phone LIKE ‘%4087’ ;

这条 SQL 有两种执行方式:

1、根据组合索引查出所有名字是’陈艮’的二级索引数据，然后回表，到主键索引上查询全部符合条件的数据(19 条数据)。然后返回给 Server 层，在 Server 层过滤出手机号码后四位为4087这个人。
2、根据组合索引查出所有名字是’陈艮’的二级索引数据(19 个索引)，然后从二级索引中筛选出手机号码后四位为4087的索引(1 个索引)，然后再回表，到主键索引上查询全部符合条件的数据(1 条数据)，返回给 Server 层。

很明显，第二种方式到主键索引上查询的数据更少。

注意，索引的比较是在存储引擎进行的，数据记录的比较，是在 Server 层进行的。而当 phone 的条件不能用于索引过滤时，Server 层不会把 phone 的条件传递给存储引擎，所以读取了两条没有必要的记录。

这时候，如果满足 name=’陈艮’的记录有 100000 条，就会有 99999 条没有必要读取的记录。

执行以下 SQL，Using where:

mysql> EXPLAIN SELECT * FROM user WHERE name= ‘陈艮’ AND phone LIKE ‘%4087’;

±—±------------±------------±-----------±-----±------------------±------------------±--------±------±-----±---------±------------+

±—±------------±------------±-----------±-----±------------------±------------------±--------±------±-----±---------±------------+

| 1 | SIMPLE | user_innodb | NULL | ref | comidx_name_phone | comidx_name_phone | 1023 | const | 19 | 11.11 | Using where |

±—±------------±------------±-----------±-----±------------------±------------------±--------±------±-----±---------±------------+

1 row in set, 1 warning (0.00 sec)

Using Where 代表从存储引擎取回的数据不全部满足条件，需要在 Server 层过滤。

先用 name条件进行索引范围扫描，读取数据表记录，然后进行比较，检查是否符合 phone LIKE ‘%4087’ 的条件。此时 19 条中只有 1 条符合条件。

五、索引创建使用总结

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

因为索引对于改善查询性能的作用是巨大的，所以我们的目标是尽量使用索引。

5.1. 索引的创建

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

根据上一节的分析，我们总结出索引创建的一些注意点：

1、在用于 where 判断 order 排序和 join 的(on)字段上创建索引
2、索引的个数不要过多。——浪费空间，更新变慢。
3、区分度低的字段，例如性别，不要建索引。——离散度太低，导致扫描行数过多。
4、频繁更新的值，不要作为主键或者索引。 ——页分裂
5、组合索引把散列性高(区分度高)的值放在前面。——最左前缀匹配原则
6、创建复合索引，而不是修改单列索引。——组合索引代替多个单列索引（由于MySQL中每次只能使用一个索引，所以经常使用多个条件查询时更适合使用组合索引）
7、过长的字段，怎么建立索引?——使用短索引。

当字段值比较长的时候，建立索引会消耗很多的空间，搜索起来也会很慢。我们可以通过截取字段的前面一部分内容建立索引，这个就叫前缀索引。

create table shop(address varchar(120) not null);

alter table shop add key (address(12));

8、不建议用无序的值(例如身份证、UUID )作为索引——当主键具有不确定性，会造成叶子节点频繁分裂，出现磁盘存储的碎片化

5.2. 什么时候会用不到索引

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

1、索引列上使用函数(replace\SUBSTR\CONCAT\sum count avg)、表达式、计算(+ – * /):

explain SELECT * FROM ‘t2’ where id+1 = 4;

2、字符串不加引号，出现隐式转换

explain SELECT * FROM ‘user’ where name = 136;

explain SELECT * FROM ‘user’ where name = ‘136’;

3、like 条件中前面带%

where 条件中 like abc%，like %2673%，like %888 都用不到索引吗?为什么?

explain select * from user where name like ‘wang%’;

explain select * from user where name like ‘%wang’;

过滤的开销太大，所以无法使用索引。这个时候可以用全文索引。

4、负向查询

NOT LIKE 不能:

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

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

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

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

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

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

难道这样就够了吗？不，远远不够！

提前多熟悉阿里往年的面试题肯定是对面试有很大的帮助的，但是作为技术性职业，手里有实打实的技术才是你面对面试官最有用的利器，这是从内在散发出来的自信。

备战阿里时我花的最多的时间就是在学习技术上，占了我所有学习计划中的百分之70，这是一些我学习期间觉得还是很不错的一些学习笔记

我为什么要写这篇文章呢，其实我觉得学习是不能停下脚步的，在网络上和大家一起分享，一起讨论，不单单可以遇到更多一样的人，还可以扩大自己的眼界，学习到更多的技术，我还会在csdn、博客、掘金等网站上分享技术，这也是一种学习的方法。

今天就分享到这里了，谢谢大家的关注，以后会分享更多的干货给大家！

阿里一面就落马，恶补完这份“阿里面试宝典”后，上岸蚂蚁金服

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
…(img-qb1k7El6-1713252291806)]

[外链图片转存中…(img-7aZvkcQI-1713252291806)]

[外链图片转存中…(img-XDVuLNWO-1713252291806)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

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

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

难道这样就够了吗？不，远远不够！

备战阿里时我花的最多的时间就是在学习技术上，占了我所有学习计划中的百分之70，这是一些我学习期间觉得还是很不错的一些学习笔记

今天就分享到这里了，谢谢大家的关注，以后会分享更多的干货给大家！

[外链图片转存中…(img-zN46Iuzw-1713252291807)]

[外链图片转存中…(img-SeLd3Jvu-1713252291807)]

[外链图片转存中…(img-eVi7pcfO-1713252291807)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

2301_79055107

关注

4
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
MySQL索引由浅入深！万字长文详解MySQL

总结一下，InnoDB 中的 B+Tree 的特点:它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。B Tree 解决的两大问题是什么?(每个节点存储更多关键字；路数更多)2)扫库、扫表能力更强(如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵 B+Tree 拿到所有的数据)B+Tree 的磁盘读写能力相对于 B Tree 来说更强(根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多)
复制链接

扫一扫