Sql优化(详解一条龙服务)

---

一:整体的优化思路

• 定位查询慢的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