SQL 优化 MySQL 版 - -B 树索引详讲
作者: Stanley 罗昊
为什么要进行 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 树本身就是一个排好序的结构, 最左边必然是最小的, 最最右边必然是最大的:
只需要根据一定的规则遍历出来就行了.
今日感悟:
很多父母或者年轻人找工作细化追求一份 "铁饭碗",
认为稳定最重要,
但在这个世界上, 唯一不变的铁律就是变化,
不管是公务员, 还是国企, 都只有靠能力, 在岗位上才能站稳脚,
什么是真正的铁饭碗?
铁饭碗绝不是在一个单位干一辈子,
而是到了那儿, 你都有饭吃, 荒年饿不死手艺人, 能力才是硬道理!
来源: https://www.cnblogs.com/StanleyBlogs/p/10413349.html