MySQL数据库作为优秀的关系型开源数据库，受到所有人的青睐，我们日常工作中，和其打交道的次数十分频繁，那么你知道我们在写sql的时候，MySQL内部是如何执行的吗？接下来我们就一起探讨一下吧。

MySQL 基本架构

以这条sql语句为例：

select * from T where ID=10;

当我们执行该查询语句时，会收到MySQL给我们返回的结果，那么其在MySQL中是如何一步步执行的呢？
首先我们了解一下MySQL的架构图，看一下MySQL服务的组织结构：

如上图所示：
MySQL大致可以分为 Server 层和存储引擎层两部分。
Server 层包括连接器、查询缓存、分析器、优化器、执行器等，以及所有内置的函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，如存储过程、触发器、视图等。
存储引擎层则负责数据的存取。架构是插件式的，支持 InnoDB、MyISAM、Memory等多个存储引擎。MySQL 5.5.5版本之后，其默认存储引擎为InnoDB。
所有的存储引擎共用一个Server层。

连接器（Connector）

在查询 SQL 语句前，肯定要先建立与 MySQL 的连接，这就是由连接器来完成的。连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令为：

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

输完命令之后，你就需要在交互对话里面输入密码。虽然密码也可以直接跟在 -p 后面写在命令行中，但这样可能会导致你的密码泄露。如果你连的是生产服务器，强烈建议你不要这么做。
连接命令中的 mysql 是客户端工具，用来跟服务端建立连接。在完成经典的 TCP 握手后，连接器就要开始认证你的身份，这个时候用的就是你输入的用户名和密码。
如果用户名或密码不对，你就会收到一个"Access denied for user"的错误，然后客户端程序结束执行。
如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。
这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。
连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。结果如下：

+----+------+----------------+------------------+---------+------+----------+------------------+
| Id | User | Host           | db               | Command | Time | State    | Info             |
+----+------+----------------+------------------+---------+------+----------+------------------+
|  3 | root | localhost:2790 | NULL             | Sleep   | 5878 |          | NULL             |
|  4 | root | localhost:2791 | blog             | Sleep   | 5838 |          | NULL             |
|  7 | root | localhost:2900 | blog             | Sleep   | 5838 |          | NULL             |
| 10 | root | localhost:3627 | blog             | Query   |    0 | starting | show processlist |
+----+------+----------------+------------------+---------+------+----------+------------------+

客户端如果长时间处于Sleep，连接器会将其自动断开，断开时间基于配置的 wait_timeout 参数，默认值是8小时。
如果连接断开之后，客户端再次发送请求的话，就会收到错误：Lost connection to MySQL server during query。此时，继续执行请求就需要重连。

长连接

MySQL中，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很小的几次查询就断开连接，下次查询重建新连接。
建立连接的过程一般是比较复杂的，所以我们应该尽量使用长连接。
但是并不是说长连接就没有问题，因为MySQL执行过程中临时使用的内存是管理在连接对象中的，所以每次执行完请求，都会增加连接的内存占用，这些资源一直不释放会导致内存爆满，被系统强行kill掉，从现象上看就是MySQL异常重启了。
那么解决这个问题的方案就需要考虑以下两点：
1、定期断开长连接，或在程序中判断某个连接内存占用过大，就将其关闭，之后使用再连接即可。
2、MySQL 5.7之后的版本，有一个 mysql_reset_connection 的函数可以重新初始化连接资源，也就是释放该连接占用的内存。这个过程不需要重连和重新做权限验证就会将连接恢复到刚刚创建完时的状态。

查询缓存（Query Cache）

在建立连接后，就开始执行 select 语句了，执行前首先会查询缓存。
MySQL 拿到查询请求后，会先查询缓存，看是不是执行过这条语句。执行过的语句及其结果会以 key-value 对的形式保存在一定的内存区域中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。
如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。如果查询命中缓存，MySQL 不需要执行后面的复杂操作，就可以直接返回结果，会提升效率。
但是大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。好在 MySQL 也提供了这种“按需使用”的方式。你可以将参数 query_cache_type 设置成 DEMAND，这样对于默认的 SQL 语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 SQL_CACHE 显式指定，像下面这个语句一样：

mysql> select SQL_CACHE * from T where ID=10；

需要注意的是，MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开始彻底没有这个功能了。

分析器（Analyzer）

如果查询缓存未命中，就要开始执行语句了。首先，MySQL 需要对 SQL 语句进行解析。
分析器先会做词法分析。SQL 语句是由多个字符串和空格组成的，MySQL 需要识别出里面的字符串分别是什么，代表什么。MySQL 从你输入的 select 这个关键字识别出来，这是查询语句。它也要把字符串 T 识别成表名，把字符串 ID 识别成列名。之后就要做语法分析。根据词法分析的结果，语法分析器会根据语法规则，判断输入的 SQL 语句是否满足 MySQL 语法。
如果你 SQL 语句不对，就会收到 You have an error in your SQL syntax 的错误提醒，比如下面这个语句 from 写成了 form。

mysql> select * form T where ID = 10;
1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'form T where ID = 10' at line 1

一般语法错误会提示第一个出现错误的位置，所以要关注的是紧接 use near 的内容。

优化器（Optimizer）

Mysql通过分析器知道你要做什么，在开始执行之前，还要先经过优化器的处理。
优化器是在表里面有多个索引的时候，决定使用那个索引；或者在一个语句有多表关联（join）的时候。决定各表的连接顺序。比如你执行这个语句

mysql> select * from t1 join t2 using(ID)  where t1.c=10 and t2.d=20;

既可以先从表 t1 里面取出 c=10 的记录的 ID 值，再根据ID关联到表t2，再判断t2里面d的值是否等于20。
也可以先从表t2里面取d=20的值，再根据ID关联到表t1，再判断t1里面c的值是否等于10。
这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。
优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。

执行器（Actuator）

MySQL 通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。
开始执行的时候，要先判断一下你对这个表 user_info 有没有执行查询的权限，如果没有，就会返回没有权限的错误，如下所示 (如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。查询也会在优化器之前调用 precheck 验证权限)。

mysql> select * from T where ID=10;
ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。
比如我们这个例子中的表 T 中，ID 字段没有索引，那么执行器的执行流程是这样的：
调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果是则将这行存在结果集中；
调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。
至此，这个语句就执行完成了。
对于有索引的表，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的。
你会在数据库的慢查询日志中看到一个 rows_examined 的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟 rows_examined 并不是完全相同的。

问题

1、在执行器阶段为什么要判断对表是否具有执行查询的权限，而不是在分析器去判断？根据 MySQL 中的 information_schema 库的存储信息，理论上可以在分析器阶段判断是否有权限。
有时sql语句要操作的表不只是sql字面上的那些，比如有个触发器，得在执行器阶段才能确定，所以优化器前判断权限有时候不完整。

一些容易漏掉的知识

1、连接器是从权限表里面查询用户权限并保存在一个变量里面以供查询缓存、分析器、执行器在检查权限的时候使用。
2、sql在执行的过程中，可能会有触发器这种在运行时才能确定是否有相应权限的操作，分析器工作结束后的 precheck 操作是不能对这种运行时涉及到的表进行权限校验的，所以需要在执行器阶段进行权限检查。另外也是因为有precheck这个步骤，才会在报错时显示为用户无权，而不是字段k不存在，此举是为了不向用户暴露表结构。
3、词法分析阶段是从 information_schema 里面获得表的结构信息的。
4、可使用连接池的方式，将短连接变为长连接
5、mysql_reset_connection 是MySQL为各个语言提供的api，非sql语句。
6、wait_timeout 是非交互式连接的空闲超时，interactive_timeout 是交互式连接的空闲超时。执行时间不计入空闲时间。通过客户端连接的为交互式，通过程序连接的是非交互式