IT技术之家

首页 > 服务器

服务器

Sql优化(详解一条龙服务)_天天向上的菜鸡杰!!

发布时间:2022-10-24 16:48:35 服务器 0次 标签:sql 数据库 mysql
这个过程在mysql8.0已经取消了 为甚取消了呢 因为在我们读写操作比较多的时候 这个缓存需要频繁的更新 那么我们还没有用到这个缓存 他就已经更新了。任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。所有第一步我们需要先定位出 查询比较慢的sql 然后的话 我们将其单拎出来 进行优化。在这里的话 ,如果我们的sql又臭又长的话 那么肯定是解析的比较慢的。那么我们应该 回顾一下 我们的sql select历程。这个阶段是没有什么可优化的。...


文章目录

@[TOC] 一:整体的优化思路二:优化思路流程1:sql 优化 嗯哼 优化什么 sql吗? 哪来的sql 呀2:那么一条sql语句查询慢了的话 我们应该回顾 该sql的 执行历程 分析可优化的部分3:从客户端发送sql 到连接器4查询缓存5:词法分析跟语法分析6:预处理器7:优化器(1):优化索引(2):合理使用索引 8:其他优化

一:整体的优化思路

定位查询慢的sql回顾一条sql的查询历程分析在查询的历程当中 我们可以优化的部分

二:优化思路流程

1:sql 优化 嗯哼 优化什么 sql吗? 哪来的sql 呀

所有第一步我们需要先定位出 查询比较慢的sql 然后的话 我们将其单拎出来 进行优化

打开慢查询日志更开慢查询日志中的的 默认限制时间 (就是当我们查询时间超过一个值得时候 该日志就会被记录下来该sql语句)找到慢查询的sql

2:那么一条sql语句查询慢了的话 我们应该回顾 该sql的 执行历程 分析可优化的部分

那么我们应该 回顾一下 我们的sql select历程

首先是客户端将我们的sql 发送到mysql服务中的连接器查询缓存 (命中就返回 为命中就继续执行接下来的流程)词法分析 (检查sql语句中的关键字 后续建立语法树是需要的)语法分析 (检查我们写的sql语句是否有语法错误)生成语法树预处理 (如果我们用了select * 的话 这部会将 我们省略的部分 表示出来 进一步检查语法树是否合法 )优化器 (这里的优化器 可以优化 我们的sql 在我们选择索引的时候会 预判 是否走索引还是全局扫描 或者在复合索引的时候 调整我们的索引字段的顺序)执行sql 从储存引擎中查询出结果返回给客户端

3:从客户端发送sql 到连接器

这个阶段是没有什么可优化的

4查询缓存

这个过程在mysql8.0已经取消了 为甚取消了呢 因为在我们读写操作比较多的时候 这个缓存需要频繁的更新 那么我们还没有用到这个缓存 他就已经更新了

根据实际情景 如果我们的数据库是读写比较多的话 那么我们可以在相关配置文件中关掉这个 缓存 这样可以适当提高我们查询速度

5:词法分析跟语法分析

在这里的话 ,如果我们的sql又臭又长的话 那么肯定是解析的比较慢的

每次执行SQL的时候都要建立网络连接、进行权限校验、进行SQL语句的查询优化、发送执行结果,这个过程是非常耗时的,因此应该尽量避免过多的执行SQL语句,能够压缩到一句SQL执行的语句就不要用多条来执行

6:预处理器

任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段

避免使用 select *如果只查询一行就使用 limit 1

7:优化器

优化器主要会在索引的选择上做出预判

(1):优化索引

避免在索引上进行计算
在where字句中,如果索引列是计算或者函数的一部分,DBMS的优化器将不会使用索引而使用全表查询,函数
属于计算的一种同时在in和exists中通常情况下使用EXISTS,因为in不走索引 not in 也是
未优化的sql(主要就是优化 带有not in 的sql):
SELECT id,name,email 
FROM customer 
WHERE id 
NOT IN(SELECT id FROM payment)	

优化完的sql:
这就造成了会循环多次来查找子表来确认是否满足过滤条件,如果子查询恰好是一个很大的表的话,这样做的效率会非常低,所以我们在进行 SQL 开发时,最好把这类查询自行改写成关联查询。
select a.id,a.name,a.email from customer a left join payment b where b.id = null;
避免判断null值
未优化的sql:
select id from t where num is null;
将其优化为:
可以在num上设置默认值0,确保表中num列没有null值,
然后这样查询:
select id from t where num = 0;
避免不等值(<>)判断

(2):合理使用索引

在差别较大的列上建立索引(比如性别 sex 就不适合做索引)合理控制索引的数量对于唯一性校验的可以使用唯一索引、不要求数据唯一的使用普通索引

8:其他优化

用union all替换union (但是得根据使用情景) 当SQL语句需要union两个查询结果集合时,即使检索结果中不会有重复的记录,如果使用union这两个结果集同样会尝试进行合并,然后在输出最终结果前进行排序,因此如果可以判断检索结果中不会有重复的记录时候,应
该用union all,这样效率就会因此得到提高。数据结构优化:用varchar 代替 char