【MySQL】之语句执行过程分析

MySQL的语句执行过程可以表示如下：

• 首先客户端连接MySQL的连接器，连接成功后，先到查询缓存看看，之前是不是执行过这条语句，如果能够命中就返回缓存的value；
• 如果没有缓存则进入词法分析器对SQL语句进行词法解析；
• 语句分析完毕后进入优化器进行SQL语句优化；
• 最后交给引擎执行语句。

MySQL连接

---

我们要进行查询，第一步就是先去链接数据库，那这个时候就是连接器跟我们对接。连接器负责跟客户端建立链接、获取权限、维持和管理连接。

链接数据库的过程会经过TCP握手，然后身份验证，输入用户名和密码验证成功后，我们就连上了这个MySQL服务了，但是这个时候我们处于空闲状态。

我们可以使用 show processlist 来查看空闲连接列表，查询结果中的 Command 列如果显示为 Sleep，就表示该连接为空闲连接。

这里需要注意的是，我们数据库的客户端太久没响应，连接器就会自动断开了，这个时间参数是wait_timeout控制住的，默认时长为8小时，断开后重连的时候会报错，如果想再继续操作，就需要重连了。

除了重新链接，还可以使用长连接，但使用长连接之后，内存会飙得很快，我们知道MySQL在执行过程中临时使用的内存是管理在连接对象里面的，只有在链接断开的时候才能得到释放，那如果一直使用长连接，那就会导致OOM（Out Of Memory），会导致MySQL重启，在JVM里面就会导致频繁的Full GC。

解决长连接的问题有一下两种：

• 定期断开长连接，使用一段时间后，或者程序里面判断执行过一个占用内存比较大的查询后就断开连接，需要的时候重连就好了;
• 执行比较大的一个查询后，执行 mysql_reset_connection 可以重新初始化连接资源。这个过程相比上面一种会好点，不需要重连，但是会初始化连接的状态。

一般推荐使用第二种。

2、查询缓存

---

我们知道，同一条语句在MySQL执行两次，第一次和后面的时间是不一样的，后者明显快一些，这就是因为缓存的存在，就跟Redis一样，只要是你之前执行过的语句，都会在内存里面用key-value形式存储着。

MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句，如果能够命中就返回缓存的value，如果不命中就执行后面的阶段。

但缓存是弊大于利的！

因为缓存的失效很容易，只要对表有任何的更新，这个表的所有查询缓存就会全部被清空，就会出现缓存还没使用，就直接被清空了，或者积累了很多缓存准备用来着，但是一个更新打回原形。

这就导致查询的命中率低的可怕，只有那种只查询不更新的表适用缓存，但是这样的表往往很少存在，一般都是什么配置表之类的。

查询的时候如何显示的使不使用缓存呢？

我们可以把 query_cache_type 设置成为DEMAND，这样SQL默认不适用缓存，想用缓存就用SQL_CACHE。

或者我们可以在 sql 语句前面使用SQL_NO_CACHE：

select SQL_NO_CACHE * from test;

需要留意到是：缓存在MySQL8.0之后就取消了。

3、语法分析和优化

---

在缓存没有命中的情况下，就开始执行语句了，你写的语句有没有语法错误，这是接下来MySQL比较关心的点。

首先，会做词法分析，你的语句有这么多单词、空格，MySQL就需要识别每个字符串所代表的是什么，是关键字，还是表名，还是列名等等。

然后就开始语法分析，根据词法分析的结果，语法分析会判断你sql的对错，错了会提醒你的，并且会提示你哪里错了。

分析没错之后就进入下一步，优化器。

优化就比较简单了，因为我们建立表可能会建立很多索引，优化有一步就是要确认使用哪个索引，比如使用你的主键索引，联合索引还是什么索引更好。

还有就是对执行顺序进行优化，条件那么多，先查哪个表，还是先关联，会出现很多方案，最后由优化器决定选用哪种方案。

最后就是执行了，执行就交给执行器去做。