共计 1531 个字符,预计需要花费 4 分钟才能阅读完成。
为什么要进行 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 树本身就是一个排好序的结构,最左边必然是最小的,最最右边必然是最大的:
只需要根据一定的规则遍历出来就行了。
: