当输入一条 MySQL 语句时，这条语句是如何被执行的？ 需要经过 MySQL 哪些部分，才能将执行结果取出？ 本文章简单记录下，MySQL 语句的执行过程，并以此了解 MySQL 的组成部分。
下图是 MySQL 的基本架构示意图。
MySQL 可以分为 Server 层和存储引擎层两部分
1、Server 层包括了 连接器、查询缓存、分析器、优化器、执行器等，涵盖了 MySQL 的大多数核心服务功能1111，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在 Server 层实现，比如存储过程、触发器、视图等。
2、存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。 目前最常见的存储引擎是 InnoDB。
连接器
首先，从客户端发起请求，连接到数据库上，这时处理请求的就是 MySQL 的连接器。 连接器负责和客户端建立连接、获取权限、维持和管理连接。
连接命令一般如下：
mysql -h$ip -P$port -u$user -p
在连接MySQL 成功后，连接器会到权限表中查询此用户拥有的权限。 一个用户成功建立连接后，如果此用户的权限在连接中被修改，不会影响到当前存在的连接权限。 只有重新建立连接，连接器才会从权限表中重新读取新的权限设置。
如果想要查询当前 MySQL 的连接状态，可以通过 show processlist 命令看到：
其中， Command 是指当前连接的状态，如果连接完成后，一直没有后续动作，此状态会变成 "Sleep"。如果此空闲连接一直没有动静，连接器会将此连接断开。这个时间由 wait_timeout 控制，默认为8小时。
数据库中，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，等待下次查询再重新建立一次连接。
建立连接的过程通常比较复杂，所以一般建议使用长连接。
但是全部使用长连接后，可能会发现，有时候 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开时才释放。 所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），也就是 MySQL 异常重启。
考虑一下两种方案解决此问题：
1、定期断开长连接。或者程序中判断执行过一个占用内存的大查询后，断开连接。
2、如果使用的是 MySQL5.7及以上版本，可以在执行一个大操作后，通过执行 mysql_reset_connection 来初始化连接资源。
查询缓存
MySQL 在连接建立完成后，拿到一个查询请求，会到查询缓存中看看，之前是否执行过此语句。 因为之前执行过的语句及其结果可能会以 key-value 的方式存在缓存中。 如果查询的请求命中的某个查询缓存中的 key，其 value 会被直接返回给客户端。
如果查询语句不在查询缓存中，则继续执行后续步骤。执行完成后，其结果会被存入查询缓存中。
当对一个表有更新时，此表上的所有查询缓存会被清空。 这也就导致查询缓存非常容易失效，所以，大部分情况下，其实不建议使用查询缓存。
分析器
当查询请求未命中查询缓存，则 MySQL 开始真正执行此语句。
请求会来到 分析器 中，对 SQL语句做解析。
如果请求的 SQL 语句语法有问题，或者说请求的表不存在等等，分析器会返回错误信息。
优化器
MySQL 通过分析器知道了请求的 SQL 语句要“做什么”后，会通过优化器来决定 “怎么做”。
优化器会在表中有多个索引时，决定使用哪个索引。或者在一个语句中有多表关联时，决定表的关联顺序。
执行器
接下来进入 MySQL 的执行器，开始执行语句。
开始执行前，会判断此用户是否有对 SQL 请求中的表有对应的执行权限。
然后， 执行器会打开表继续执行。 执行器会根据表的引擎定义，使用这个引擎提供的接口。
