「mysql优化专题」这大概是一篇最好的mysql优化入门文章(1)

【mysql优化专题】:本专题全文围绕mysql优化进行全方位讲解,本篇为优化入门篇,让大家知道为什么要优化,究竟在优化什么。喜欢的朋友可以关注收藏。

优化,一直是面试最常问的一个问题。因为从优化的角度,优化的思路,完全可以看出一个人的技术积累。那么,关于系统优化,假设这么个场景,用户反映系统太卡(其实就是高并发),那么我们怎么优化?

  • 如果请求过多,判定web服务器的压力过大,增加前端的web服务器,做负载均衡
  • 如果请求静态界面不卡了,但是动态数据还是卡,说明MySQL处理的请求太多了,在应用层增加缓存.
  • 数据库层其实是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截掉,数据库层只承担“能力范围内”的访问请求,所以,我们通过在服务层引入队列和缓存,让最底层的数据库高枕无忧。但是如果请求激增,还是有大量的查询压力到MySQL,这个时候就要想办法解决MySQL的瓶颈了

总结起来就是,系统优化的第一步,是绝对轮不到MySQL优化我们之所以要做MySQL的集群,一般都是在做好了应用级别的缓存,请求还是太多的情况下考虑的问题.

MySQL的执行流程

那么,要知道我们平时常说的优化sql到底是在优化些什么,就必须弄懂MySQL的执行流程。而这个专题将系统化的由浅到深讲解MySQL一些高级用法。打算先讲很多人关注的使用方式(增删改查以及其优化),然后就讲数据库和表的操作(很多我们学习忽略的地方),接着就是引擎还有更高级的查询等等。

先简单粗暴上一执行流程图感受下

大致可以分为以下十个步骤:

1.当我们请求mysql服务器的时候,MySQL前端会有一个监听,请求到了之后,服务器得到相关的SQL语句,执行之前(虚线部分为执行),还会做权限的判断

2.通过权限之后,SQL就到MySQL内部,他会在查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回,说明在MySQL内部,也有一个查询缓存.但是这个查询缓存,默认是不开启的,这个查询缓存,和我们的Hibernate,Mybatis的查询缓存是一样的,因为查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的(没什么卵用的意思)。

3.如果我们没有开启查询缓存,或者缓存中没有找到对应的结果,那么就到了解析器,解析器主要对SQL语法进行解析

4.解析结束后就变成一颗解析树,这个解析树其实在Hibernate里面也是有的,大家回忆一下,在以前做过Hibernate项目的时候,是不是有个一个antlr.jar。这个就是专门做语法解析的工具.因为在Hibernate里面有HQL,它就是通过这个工具转换成SQL的,我们编程语言之所以有很多规范、语法,其实就是为了便于这个解析器解析,这个学过编译原理的应该知道.

5.得到解析树之后,不能马上执行,这还需要对这棵树进行预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在什么地方,如果有计算的东西,把计算的结果算出来等等...

6.预处理完毕之后,此时得到一棵比较规范的树,这棵树就是要拿去马上做执行的树,比起之前的那棵树,这棵得到了一些优化

7.查询优化器,是MySQL里面最关键的东西,我们写任何一条SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它会怎么去执行?它是先执行username = toby还是password = 1?每一条SQL的执行顺序查询优化器就是根据MySQL对数据统计表的一些信息,比如索引,比如表一共有多少数据,MySQL都是有缓存起来的,在真正执行SQL之前,他会根据自己的这些数据,进行一个综合的判定,判断这一次在多种执行方式里面,到底选哪一种执行方式,可能运行的最快.这一步是MySQL性能中,最关键的核心点,也是我们的优化原则.我们平时所讲的优化SQL,其实说白了,就是想让查询优化器,按照我们的想法,帮我们选择最优的执行方案,因为我们比MySQL更懂我们的数据.MySQL看数据,仅仅只是自己收集到的信息,这些信息可能是不准确的,MySQL根据这些信息选了一个它自认为最优的方案,但是这个方案可能和我们想象的不一样.

8.这里的查询执行计划,也就是MySQL查询中的执行计划,比如要先执行username = toby还是password = 1

9.这个执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么?就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的.那怎么执行IO又是什么来确定的?就是传过来的这一份执行计划.

10.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。

今天的mysq执行流程就讲到这里,喜欢的朋友可以收藏并关注。

原文发布于微信公众号 - java进阶架构师(java_jiagoushi)

原文发表时间:2017-11-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏idealclover的填坑日常

MySQL Error "Incorrect integer value" for column 'name' at row 1″解决方法

在使用typecho的插件时遇到了数据库的错误,通过日志回溯之后发现错误原因是MySQL Error "Incorrect integer value" for...

8433
来自专栏IT米粉

数据库的使用你可能忽略了这些

很明显,不同的类型存储的长度有很大区别的,对查询的效率有影响,字段长度对索引的影响是很大的。

45010
来自专栏杨建荣的学习笔记

在线重定义的补充测试(r10笔记第26天)

在很多时候,我们都是需要保持业务的可持续性,尽管说DDL的过程持续时间很短,但是在线业务出现,就会阻塞DML,导致业务访问中断,事务收到影响,所以在有些...

3548
来自专栏DeveWork

免插件仅代码实现WordPress评论回复邮件

许多wordpress博主为增加与读者的互动,从而获得更加多的“回头客”,常常在评论上启用一个“评论回复邮件”的功能。这个功能可以使用插件来实现,但我们一贯遵循...

3818
来自专栏小怪聊职场

MySQL(五)|《千万级大数据查询优化》第二篇:查询性能优化(1)

3208
来自专栏后端技术探索

当规模到亿级,MySQL是一个更好的NoSQL!

MySQL是一个更好的NoSQL数据库。当考虑到NoSQL的使用案例,比如对Key/Value键值存储来讲,MySQL在性能、易用性和稳定性方面更有意义。MyS...

1401
来自专栏数据和云

实战课堂:系统CPU高消耗的SQL筛选和最佳索引优化

在一次客户系统性能优化项目中,经过第一阶段的优化之后,数据库的DB Time和物理读都明显降低,但是我们发现CPU并没有明显降低。

1284
来自专栏北京马哥教育

优化 SQL SELECT 语句性能的 6 个简单技巧

SELECT语句的性能调优有时是一个非常耗时的任务,在我看来它遵循帕累托原则。20%的努力很可能会给你带来80%的性能提升,而为了获得另外20%的性能提升你可能...

46611
来自专栏禁心尽力

会优化,你真的会优化吗?其实你可能真的缺少一份理解【数据库篇】

  其实,在写这篇博客之前,我也是感觉自己会点优化,至少知道不要使用“*”号啊,给经常查询的列创建索引啊什么的,其实都不是大家想的那样简单的,其实它们背后存在很...

2026
来自专栏性能与架构

数据库表设计对性能的影响

很多人看来,数据库Schema设计是一件非常简单的事情,大体按照系统设计时候的相关实体对象对应成一个一个表格就可以了。为了在功能上尽可能容易扩展,根据数据库范式...

4025

扫码关注云+社区

领取腾讯云代金券