MySQL系列之一条SQL语句走过的套路（二）

封面

在上一篇文章中我们知道了一条SQL语句会经历过连接器、分析器、优化器、执行器四个组件，最终到达存储引擎。那么每一个组件又具备什么样的作用呢？请看下文中的详细说明。

1.连接器

首先我们会使用以下的命令登录数据库：

-h$ip -P$port -u$user -p

当然我们也可以在-p后边接上用户密码，但是这样做并不安全容易导致密码泄露，尤其是在登录生产数据库的时候，所以我们尽量使用以上的命令在交互中输入密码。

如果用户名以及密码不正确，你就会收到一个“Access denied for user”的错误提示，然后客户端结束执行。

如果用户名以及密码正确输入，连接器会从权限表中读取到你的权限。之后，这个连接里所有的权限验证都依赖于你此时获取到的权限数据。所以，当你建立了连接之后，如果有人使用管理账号修改了你的权限，也不会影响到你当前的连接。而是在你下次登录之后才会生效。

有这么一种情况可能大家有遇到过，那就是当我们连接上数据库之后，并不会用完就关闭连接，经常会隔了一个晚上第二天再次使用mysql时会提示“Lost connection to MySQL server during query”。这是因为当我们长时间不使用这个连接，连接置于空闲状态且超过wait_timeout参数设定的时间后，连接器会自动断开。这个参数的默认值为8小时。我们也可以通过SHOW VARIABLES 命令来查看参数的值。

还有一种情况是有时候我们在做一些大查询的时候会发现MySQL占用内存会涨的比较快，这是因为MySQL再执行过程中临时使用的内存会在当前连接中管理。这些资源只有在连接断开的时候才会释放，如果长时间累计下来，甚至会导致内存占用过大，被系统强制杀死，造成一种MySQL异常重启的现象。了解了这个原理之后，这里提出两个方案来减少这种情况的发生：

在使用了大查询之后关闭当前连接，主动释放占用资源。

MySQL5.7之后的版本可以在大查询之后，可以通过mysql_reset_connection来重新初始化连接资源。这个过程不需要重新连接和重新做权限验证，但是会将连接恢复到刚创建完成时的状态。

2.查询缓存

在上一篇MySQL系列之一条SQL语句走过的套路（一）中提过在Server层中其实还有一个组件是查询缓存。它在连接建立完成之后，就可以执行了。

当MySQL拿到一个查询请求时，会先到查询缓存中看看，之前是不是执行过这条语句。之前执行过的语句以及结果会以KEY-VALUE对的形式，被直接缓存在内存中，如果命中缓存则直接返回结果。如果没有命中缓存，才会继续执行后续的分析器、优化器、执行器的过程。

但是正常情况下我们的配置都是关闭缓存的，为什么要这么做呢？其实是因为只要一个表有更新操作，那这个表上的所有查询缓存都会被清空。对于更新频繁的数据库来说，查询缓存的命中率会很低。可能刚把查询过的结果存起来，就被更新操作清空了缓存。徒劳无功。

需要注意的是在MySQL8.0版本直接删除了查询缓存的模块。所以我点到为止，不再继续介绍查询缓存了。想了解更多查询缓存的可以关注我，私信沟通。毕竟它既然存在了这些版本也是有实际意义的。

以上我们介绍了MySQL的Server层中查询器和查询缓存的执行过程。在下一篇文章中我们会把分析器、优化器、执行器一并说完。结束这个话题。想了解其他开发方面的知识也可以私信我。