一文读懂一条查询语句的宿命

一文读懂一条查询语句的宿命

select * from XXX where id=1;

这应该是n年前入门mysql必用的查询语句了吧，学如逆水行舟，不进则退，这么久过去了，你知道这条语句在Mysql内部的执行过程吗?

我们先来看看司空见惯的Mysql基本架构示意图

可以看到，Mysql可以分为

Server层，包括连接器、查询缓存、分析器、优化器、执行器等，除了直接落地到磁盘、和从磁盘提取数据外的所有能力。存储引擎层，负责了数据的读取和存储，支持InnoDB、MyISAM、Memory等多个存储引擎，默认的是InnoBD。

结构大概讲完了，有没有感觉，Mysql就像一个大型的加工厂，你把原材料，也就是sql语句放进去，然后Mysql就转动起来，从头到尾给你加工，最后得出一款产品，也就是执行结果。

嗯，这个比喻好，确实他妈的像，那么这个加工厂具体做了啥呢?

连接器小妹妹

首先，我们都会使用连接命令连上mysql

mysql -hip-pport -u$user -p

这个时候，出来接待我们的就是连接器小妹妹了

连接器小妹妹负责跟我们进行了典型的TPC握手，然后开始问我们的身份，要拿芝麻开门什么的密码来验证我们是否有权限，如果账户或者密码错误了，则会直接跟我们说

"Access denied for user“

验证通过了，则我们和连接器的连接便成功简历了，可以使用

show processlist

查看连接的状态

其中Sleep状态表明是空闲连接

连接建立后，连接器小妹妹还会告诉我们一些规则，比如

如果连接太长时间没动静，则会自动将连接断开，默认是8个小时

如果连接被断开了，等我吗再次发送请求的时候，连接器小妹妹则会告诉我们

Lost connection to MySQL server during query

那么能改吗?

可以的，只需要我们告诉连接器小妹妹，将wait_timeout的参数修改一下就可以了

听起来都是长连接，那么能进行短连接吗?

可以的，连接器小妹妹说了：

如果你们和我建立长连接的话，连接成功后，你们后续有请求，都会一直使用同一个连接。但是如果是短连接，则每次执行完很少的几次操作后我就要就断开连接了，下次再来你们再建立一次连接吧

我们也可以看到，其实和连接器小妹妹建立连接的过程是挺麻烦的，所以平常我们尽量会减少这个行为，一般都会使用长连接。

但是啊，有时候用着用着，mysql这边内存涨的特别快，这是为什么呢?我特地问了连接器小妹妹，她告诉我

mysql在执行过程中临时使用的内存是管理在连接对象里边的，而这些对象只有在连接断开的时候才释放，所以内存占用越来越大，最后有可能被系统强行干掉了，也就是OOM

丢，这么严重，那么我到底用长连接还是短连接呢?

肯定是长连接啦，别急，还是有解决办法的，我们这边给了两个方案

定期断开长连接，使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开 连接，之后要查询再重连。如果你用的是MySQL 5.7或更新版本，可以在每次执行一个比较大的操作后，通过执行mysql_reset_connection来重新初始化连接资源。这个过程不需要重连和重新做权限验证， 但是会将连接恢复到刚刚创建完时的状态。

到了这里，连接器小妹妹的活就干完了，后面出来接待我们的是缓存查询小哥哥。

缓存查询小哥哥

缓存查询小哥哥也比较简单，一来就将我们的sql语句拿去做对比，他那边有个字典，用key-value的格式记录着查询过的key和结果，而他的做法也极其简单，只要找到一样的，则将结果给回我们了，只有当找不到记录，才会继续走后面的流程，然后继续记录到字典内。

这个时候，我就很疑惑了，如果实际上数据更新了，但是你的字典还是旧的怎么办呢?

缓存查询小哥哥说了，这个不用担心，字典上会记录着查询记录对应的表，如果对应的表有了更新，我这边就会将记录全部清空掉的。

哦，这样子，那么如果是更新比较频繁的情况，可能你的作用也不大哦哈哈哈

是的，你们可以通过

query_cache_type = DEMAND

将关闭掉的，而且在8.0开始，我已经被移除啦。

说完缓存查询小哥哥流下了悲伤的泪水，是啊，毕竟跟不上时代的技术，被淘汰也是难免的。

缓存查询小哥哥说完，便将另一位小哥叫了出来，这位小哥叫分析器。

分析器小哥哥

分析器小哥哥在拿到sql语句后，就开始自己捣鼓了起来，那么他具体做了啥呢?我们在旁边看捣鼓了很久，其实他就做了两步

第一步，词法分析，就是从SQL 语句中提取关键字，比如：查询的表，字段名，查询条件等等。

第二步，语法规则，就是判断SQL语句是否合乎MySQL的语法。

通过分析器小哥哥做的事情，我也明白了，其实词法分析就是将整个SQL语句拆分成一个个单词，而语法规则则根据MySQL定义的语法规则生成对应的数据结构，并存储在对象结构当中。

举个例子，假设有这样一个SQL语句“select id from XXX”。

先通过词法分析，从左到右逐个字符进行解析

然后再通过语法规则解析，判断输入的SQL 语句是否满足MySQL语法，并且生成语法树，语法树大概是这样的

优化器小姐姐

到了这里，优化器小姐姐已经知道我们要干嘛了 毕竟分析器小哥哥已经帮他分析好了，只是可能我们的语句不够优美，所以才需要知心的优化器小姐姐来做优化。

知心小姐姐怎么做的呢?我们看到小姐姐先将SQL语法树拿了出来，然后就开始工作了起来，不得不说，小姐姐工作的样子是真的好看，那么她具体做了啥呢?

在全程围观的我们，看到了她大概做了两件事

逻辑变化代价优化

逻辑变化是啥呢?逻辑变换就是在关系代数基础上进行变换，其目的是为了化简，同时保证SQL变化前后的结果一致，也就是逻辑变化并不会带来结果集的变化。

其主要包括以下几个方面：

否定消除：针对表达式“和取”或“析取”前面出现“否定”的情况，应将关系条件进行拆分，从而将外层的“NOT”消除。等值常量传递：利用了等值关系的传递特性，为了能够尽早执行“下推”运算。“下推”的基本策略是，始终将过滤表达式尽可能移至靠近数据源的位置。常量表达式计算：对于能立刻计算出结果的表达式，直接计算结果，同时将结果与其他条件尽量提前进行化简。

总结下来就是替换和预处理啦。

代价优化呢?代价优化是用来确定每个表，根据条件是否应用索引，应用哪个索引和确定多表连接的顺序等问题，为了完成代价优化，需要找到一个代价最小的方案。

可以这说，我们要执行的查询都是通过代价优化来计算出来的，最终得出了最小代价计划去执行。

优化好后，接下来就是我们的执行器大哥出马了。

执行器大哥

到了这一步，就要准备执行了，开始执行的时候，执行器大哥会一脸严肃的翻看他的权限宝典

查看我们是否有执行查询的权限，如果没有，则会直接告诉我们

如果验证没问题，他则会根据表的引擎信息，判断要调用哪种引擎接口

例如SQL：select * from XXX where id=1;

假设 “id“ 字段没有设置索引，就会调用存储引擎从第一条开始查，如果碰到了id是1， 就将结果集返回，没有查找到就查看下一行，重复上一步的操作，直到读完整个表或者找到对应的记录。

执行器还画了个草图解释了他一贯的执行顺序

最后

一条查询命令到了这里就算结束了，大致介绍了查询请求的执行流程，引入了连接器、查询缓存、分析器、优化器、执行器几兄弟的分工合作，最后，我们为即将消失的查询缓存器弟弟默哀三分钟......

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。