MySQL优化中B树索引知识点总结

共计 1602 个字符，预计需要花费 5 分钟才能阅读完成。

自动写代码机器人，免费开通

为什么要进行 SQL 优化呢？很显然，当我们去写 sql 语句时：

1 会发现性能低
2. 执行时间太长，
3. 或等待时间太长
4.sql 语句欠佳，以及我们索引失效
5. 服务器参数设置不合理

SQL 语句执行过程分析

1. 编写过程：

编写过程就是我们平常写 sql 语句的过程，也可以理解为编写顺序，以下就是我们编写顺序：

select from join on where 条件 group by 分组 having 过滤组 order by 排序 limit 限制查询个数

我们虽然是这样去写的，但是它 mysql 的引擎去解析时，并不是依照我们以上编写的这样的顺序；

它并不是先解析 select 而是先解析 from，也就说，我们的解析过程跟编写过程是不一致的，所以我们看下发的解析顺序

2. 解析过程：

from on join where group by having select order by limit 

以上就是 mysql 的解析过程，我们发现，跟我们编写的过程完全不一致！

索引

什么是索引 (index)？简单的来讲就是书的目录；

比如说我现在要通过字典来查“王”这个字，如果你在没有目录的情况下去找“王”这个字，你就需要把这个字典从头到尾的翻一遍，如果有一千页，你就必须一页一页的去翻，直到找到为止；

索引就相当于目录，查这个“王”之前先去翻看目录，发现“W”在 300 页，因为王首字母是“W”，我们直接去在 300 页中找，这样找起来就非常快；

索引在数据库中是关键字 insex, 用官方的定义的意思来说，索引就是帮助 MySQL 快速高效的获取数据的数据结构；

索引是一个数据结构，它是一个为了高效查询数据的数据结构；

那它到底是什么数据结构呢？

其实它就是一个树，我们用的比较多的就是 B 树、Hash 树，在 MySQL 里面，用的就是 B 树索引；

B 树索引

首先我画一个图，假装这个是数据表，并且给 age 列加一个索引：

就把这个索引当成一个目录，也就是 age 为 50 的，就指向第一行，age 为 33 的，指向第五行；

下面我会将 B 树索引画出来，看看到底是怎么索引了：

我们给 age 加了索引列后，它就会像树一样，把小的放到左边，把大的放到右边，第一列为 50，比 50 小的在左边，23，比 23 小的继续向左排列，

33 比 23 大，就向左排列 20 比 22 小就在 22 后面继续向左排列，以此类推！

比如我们现在需要查 33:

select * From 表名 where age = 33;

不加索引的话，就会从 50 开始查，50 不是 23，不是 22 不是 ….，不加索引就一个个去找；

如果加索引的话，找 33，发现 33 比 50 小，第一次，再去找 23，第二次，33 比 23 大，第三次，仅需三次就查到了：

索引的弊端

1. 索引本身很占空间，可以存放在内存 / 硬盘（通常）

2. 索引不是所有情况均可适用比如：少量数据、频繁更新的字段（如果数据表中的某一列经常会发生改变，那么这一列就不适合做索引）

3. 索引确实可以提高查询效率，但是同时会降低增删改的效率，比如：

我们没有索引，你改 44，改成 45，很好改，直接改就行了，如果你有索引，我不光要改表里面的 44，我需要把 B 树里面的 44 也要改：

有些人就觉得不划算了，提升一个降低三个，这样就很不划算了，其实很划算的！

因为我们大部分情况下都是在查询，增删改很少，因为查询影响性能很大的，所以非常有必要使用它

索引的优势

1. 提高了查询效率

客户端到服务端，链接服务端是通过 IO，通过输入输出流，所以说，提高查询效率就是降低了 IO 的使用率

2. 降低 CPU 使用率

比如说我 sql 里面有一个 order by desc 根据年龄降序或升序，如果没有索引，你需要把 age 全部拿出来全部排个序，但是如果有了索引，你就不需要排序了，B 树本身就是一个排好序的结构，最左边必然是最小的，最最右边必然是最大的：

只需要根据一定的规则遍历出来就行了。

以上就是相关的 B 数索引的相关知识点，感谢大家的阅读和对丸趣 TV 的支持。

向 AI 问一下细节

丸趣 TV 网 – 提供最优质的资源集合！