原文：MySQL系统学习（01）：基础架构，一条SQL查询语句是如何执行的
前言
学习技术，不应该直接陷进细节里，我们应该首先鸟瞰其全貌，这样可以帮助我们从高维度理解问题，然后在一步步的纠其细节。同样对于MySQL的学习也是如此。
MySQL作为一个最基础的DB存储，同时也是我们开发中使用最多的一个DB，可能你会跟我之前一样觉得是只要会常用的SQL，能够满足我们日常的开发就足够了，但是作为一名开发人员，对应MYSQL原理和细节的了解可以帮助我们更好的使用它。所以有必要系统的学习它，我认为只要彻底的掌握了MYSQL，那再去学习其他的关系型DB或者NoSQL也就更容易上手了。
平时我们在使用数据库，看到的通常都是一个整体。比如，我有个最简单的表，表里只有一个ID字段，在执行下面这个查询语句时：
mysql> select * from T where ID = 10;
我们看到的只是输入一条语句，返回一个结果，却不知道这条语句在MYSQL内部的执行过程。
所以今天我想把MYSQL拆解下，看看里面都有哪些“零件”，希望可以借由这个拆解的过程，对MYSQL有更深的理解。这样当我们碰到MYSQL的一些异常或者问题时，就能够直戳本质，更为快捷的定位并解决问题。
MySQL基础架构
这个是我画的一个MySQL基础架构示意图，从中可以清楚到的看到SQL语句在MySQL的各个模块中的执行过程。
大体来说MySQL可以分为Server层和存储引擎层两部分。
Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL大部分核心服务功能，以及所有的内置函数(如日期、时间、数学和加密函数等)，所有跨存储引擎的过程都在这一层实现，如存储过程、触发器、视图等。
而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最长用的存储引擎是InnoDB，他从5.5.5版本开始成为默认存储引擎。
也就是说，我们执行create table建表的时候如果不指定存储引擎，默认使用的就是InnoDB。不过，我们也可以通过指定存储引擎的类型选择别的存储引擎。比如在create table的时候指定negine=memory，来制定内存引擎来创建表。不同存储引擎的表数据存取方式不同，支持的功能也不同，后面的学习笔记中会专门抽出去记录的。
从图中不难看出，不同的存储引擎共用一个Server层，也就是从连接器到执行器部分。我们暂时只需要对各个组件的名字有个印象，接下来我会结合开头提到的那条SQL语句，一块走一遍执行流程，依次看下每个组件的作用。
连接器
第一步，我们会连接都这个数据库上，这时候接待我们的就是连接器。连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般这么写：
mysql -h$ip -P$port -u$user -p
输完命令之后，我们需要在交互对话框中输入密码。虽然密码也可以直接跟在-p后面，但这样写可能会导致密码泄露等。如果我们连接的生产服务器，强烈建议不要这么做。
连接命令中的mysql是客户端工具，用来跟服务端建立连接。在完成经典的TCP握手之后，连接器就要开始认证我的身份，这个时候用的就是我输入的用户名和密码。
（1）如果用户名和密码不对，我们就会收到一个“Access denied for user”的错误，然后客户端程序结束执行。
（2）如果用户名跟密码认证通过，连接器会在权限表里查出我所拥有的权限。之后这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。
这就意味着，一个用户成功建立连接后，即使我们用管理员账号对这个用户权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建连接才会使用新的权限设置。
连接完成后，如果我们没有后续的动作，这个连接就处于空闲状态，我们可以在show processlist命令中看到它。文本中这个图是show processlist的结果，其中的Command列显示为“Sleep”的这几行，就表示现在系统里面存在几个空闲连接。
客户端如果太长时间没有动静，连接器就会将它断开，这个时间是由wait_timeout控制的，默认时间是8小时。
如果在连接被断开之后，再次发起请求的话，就会收到一个错误提醒：“Lost connection to MySQL server during query” 这时候如果我们要继续请求，就需要重连，然后在执行请求。
数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。
短连接指每次执行完很少的几次查询就断开了连接，下次查询在重新建立一个。
建立连接的过程通常是比较复杂的，所以我建议在使用中尽量减少建立连接的动作，也就是尽量使用长连接。
但是全部使用长连接后，我们又会发现有些时候会出现MySQL占用内存飙升的情况发生，这是因为MySQL在执行过程当中临时使用的内存是管理在连接对象当中的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来可能导致内存占用过大，被系统强行杀掉（OOM），现象表现为MySQL异常重启了。
那我们要怎么解决这个问题呢？可以考虑一下两种方案：
（1）定期的断开长连接。使用一段时间，或者程序里面判断执行过一个占用高内存的大查询之后，断开连接，只要要查询在重连。
（2）如果我们使用的是mySQL5.7 或更新的版本，可以在每次执行一个比较大的操作后，通过执行mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连或权限验证，但是会将连接恢复至刚刚创建完成时的状态。
查询缓存
连接建立完成时，我们就可以执行select语句了。这个时候执行逻辑就会来到第二步：查询缓存。
MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句及其结果可能会以key-value对的形式，被直接缓存在内存中。key是查询的语句，value是查询的结果。如果我们的查询能够直接在这个缓存中找到key，那么这个value就会被直接缓存到客户端。
如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存到查询缓存中。你可以看到，如果查询命中缓存，MySQL不需要执行后面的查询操作，这个效率会很高。
但是大多数情况下个人是不建议使用查询缓存的，为什么呢？因为查询缓存往往弊大于利
因为查询缓存的失效非常频繁，只要有对一个表的更新，这个表上的所有查询缓存都会被清空。因此很有可能我们费劲的把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的DB来说，查询缓存的命中率会非常的低。除非我们的业务就是一张静态表，或者很少去变动的这样一张表。比如一个系统配置表，那这种表上的查询才适合使用查询缓存。
好在mysql也提供了这种“按需使用”的方法。我们可以将参数query_cache_type设置成DEMAND，这样对于默认的SQL语句都不使用查询缓存。而对于你确定要使用查询缓存的语句可以这样写：
mysql> select SQL_CACHE * from T where ID = 10;
需要注意的是MySQL8.0版本直接将查询缓存的整个模块给拿掉了，也就是说8.0开始彻底没有这个功能了
分析器
如果没有命中查询缓存就要开始真正执行查询语句了。首先，MySQL需要知道我们真正要做什么，因此需要对SQL语句进行解析，这时就需要用到分析器。
首先分析器的主要作用是：“词法分析”和“语法分析”。
分析器回先做“词法分析”。我们输入的是由多个字符串和空格组成的一条SQL语句，MySQL需要识别出来里面的字符串分别是什么，代表什么。
MySQL从我输入的select关键词识别出来这时一条查询语句。他要把字符串“T”识别成“表名T”，把字符串“ID”识别成“字段ID”。
做完这些识别以后，就要做“语法分析”。根据词法分析的结果，预发分析器就会根据语法规则，判断我输入的这个SQL语句是否满足SQL的语法规则。
如果我们输入的语句不对，就会收到“You have an error in your SQL syntax”的错误提示，比如下面这个语句的select少写了一个s
mysql> elect * from T where ID = 10;
ERROR 1064 (42000): 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 'elect SQL_CACHE * from china_region_info_v2 where code=110101001011' at line 1
一般语法错误提示会提示第一个出现错误的位置，所以我们排查问题一般需要关注的是紧接“use near”的内容。
优化器
经过分析器，MySQL就知道我要做什么事情了。在开始执行之前，还要先经过优化器的处理。
优化器是在表里面存在多个索引的时候决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。比如我们执行下面这样的语句，这个语句是执行两个表的join：
mysql> select * from T1 t1 join T2 t2 using(ID) where t1.c = 10 and t2.d = 20;
(1) 即可以先从表t1里取出c等于10对应记录的ID值，在根据ID值关联t2表中d值等于20的记录。
(2)也可以先从表t2中找到d值等于20的记录对应的ID值，在根据ID值关联t1表中c等于10的记录。
这两种执行方法的结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定使用哪一种方案。
优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。如果目前为止你还有一些疑问，不要着急，这篇文章只是让我们了解一下MYSQL的基础结构及SQL的执行过程，至于优化器具体是如何优化，如何确定方案我会在后面的笔记中一步步记录下来，你可以提前了解一下，后面跟我记录的在比对一下，看看有什么不一样的，我们可以一块讨论，共同学习。
执行器
MySQL通过分析器知道了我们要做什么，通过优化器知道了要怎么做，于是就进入了执行器阶段，开始执行语句。
开始执行的时候，要先判断一下我们对这个表T有没有执行查询的权限，如果没有，就会提示权限的错误。
在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。查询也会在优化器之前调用precheck验证权限
如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。
比如我举例中的T表的ID字段没有索引，那么执行器的执行流程是这样的：
（1）调用InnoDB引擎接口取这张表的第一行，判断ID是否满足条件，看ID的值是不是10，如果是则将结果缓存到结果集中。如果不是则跳过。
（2）调用引擎接口取“下一行”，重复相同的逻辑判断，直到取到这个表的最后一行。
（3）执行器将上述过程中筛选出来的满足条件的记录行组成的记录及作为结果集返回给客户端。
至此，这个语句就执行完了。
对于有索引的表，执行的过程也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的。
你会数据库的慢查询中日志中看到一个rows_examined的字段，表示这条语句执行过程中扫描了多少行。这个值就是执行器每次调用存储引擎获取数据行的时候累加的。
总结
这篇笔记主要是想介绍一下MySQL的逻辑架构，希望帮助大家也帮助自己对SQL语句的完整执行流程的各个阶段有一个初步的了解。同时对MySQL内部最基础且最核心的几大“零件”及作用有一个初步的认识，这个前置的了解有助于我们后续深入的学习。
我的更多兴趣分享：[个人网站RelaxHeart网 - TEC博客](http://www.relaxheart.cn/to/master/blog
