One, background
Why do we need to learn MYSQL infrastructure to do?
The reason is simple, when we need to understand one thing, we only stand on the macro level, in order to draw peeling layers of silk cocoons to understand the problem. For example, we look at the source code of a framework, initially wanted to go study, they found that get lost, the reason is very simple, because we do not have the whole picture bird's eye view, we do not know where the entrance. So when we learn MYSQL as well. Start with the high-latitude understand the problem, which was last seen inside components, layers of dismantling, so let's have a deeper understanding of mysql. Ado, we look at the overall logic chart, as shown below.
Two, Mysql overall logical architecture
It is obvious from the figure, different storage engines share a Server layer, i.e. to the actuator from the connector portion. See Server layer including connectors, query cache, analyzer, optimizer, actuators, etc., covering most of MySQL's core service functions, as well as all of the built-in functions (such as date, time, math and encryption functions, etc.), all across storage engine functions are implemented in this layer, such as triggers, views, and so on.
The idea is the need to store and retrieve data storage layer is responsible for the engine. Its architecture model is the plug-in, support for InnoDB, MyISAM, Memory, and other storage engine. Now the most commonly used storage engine InnoDB, MySQL 5.5.5 version of it from the beginning became the default storage engine. This also explains when you create table construction of the table, if you do not specify the type of engine, the default is to use InnoDB. Of course, you can also specify the storage engine, such as create table statement using the engine = memory, to create a table using the specified memory engine. Next we have a look at a respective roles of the various components and the overall architecture of a sql execution flow.
Second, the connector
When we want to execute select * from T where ID = 1; when this statement is, of course, is the first connector helped us to establish a connection with the client is responsible for obtaining permissions, location and connection management. Connection command as follows:
mysql -h$ip -P$port -u$user -p
输完命令之后，接下来就是经典的TCP握手了，连接器就要开始认证你的身份，这个时候用的就是你输入的用户名和密码。虽然密码也可以直接跟在-p后面写在命令行中，但这样可能会导致你的密码泄露。如果你连的是生产服务器，前往不要这么做，这是生产上的禁忌。如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。
如果你连接完成后，未来的一段时间里，你没做任何操作，这个连接就处于空闲的状态，你可以通过show processlist命令中看到它，如下所示：
客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数wait_timeout控制的，默认值是8小时。
如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了。
数据库建立连接的过程通常是比较复杂的，使用中尽量减少连接的动作，也就是尽量使用长连接。因为长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个，这样造成开销很大。
但是你会发现全部使用长连接后，有些时候MySql占用的内存会飙涨的很快。这是由于MySql在执行的过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是MySql异常重启了。
那么如何解决这种现象呢？主要有两种方案
1.定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。
2.如果你使用的版本是mysql 5.7以后的版本，可以在执行一个较大的操作后，通过执行mysql_reset_connection来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。
三.查询缓存
连接建立完成后，就可以执行select语句去查询了，这时候执行逻辑就走到第二步：查询缓存。MYSQL拿到一个请求的时候，会先去缓存看有没有这个这条语句的执行结果，之前执行过的语句以及结果会以key-value 的形式缓存在内存中，当然，key就是sql语句了，value 就是之前的执行结果。如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。你可以看到，如果查询命中缓存，MySQL不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。
但是大多数情况下，强烈不建议你去使用查询缓存，这时候你们肯定会想，为什么不用呀，这不是挺好的呀？
原因一： cache 的访问由一个单一的全局锁来控制，这时候大量的查询将被阻塞，直至锁释放。所以不要简单认为设置 cache 必定会带来性能提升。
原因二：这是因为只要有对一个表的更新，这个表上所有的查询缓存都会被清空。这时候就会造成查询缓存的失效非常频繁，你费了很大劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。
mysql还是很人性化的，你以根据你的要去使用查询缓存，你可以将参数query_cache_type设置成DEMAND，这样对于默认的SQL语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用SQL_CACHE显式指定，sql例子如下所示：
mysql> select SQL_CACHE * from T where ID=10；
最近我去官网看了mysql 8.0的改变，这个查询功能整块被删掉了，也就是8.0以后的版本都没有这个功能了。
四.分析器
如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL需要对SQL语句做解析，分析器先会 词法分析 ，mysql需要识别出你这条sql语句字符串里面的字符串分别是什么，代表什么意思。
比如，mysql会根据你输入的select这个关键字识别出来，这是一个查询语句，把“T”识别成表明T，把ID识别成 列ID。接着就是进行语法分析了，根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。如果你的语法错误，就会报出如下错误：
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 * from t where ID=1' at line 1
一般语法错误会提示第一个出现错误的位置，所以关注的是紧接“use near”的内容。
五.优化器
经过了分析器后，在执行之前，还需要经过优化器的处理，为什么还需优化器呢？因为优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。比如你执行下面这样的语句，这个语句是执行两个表的join：
mysql> select * from T1 join T2 using(ID) where T1.A=1 and T2.B=2;
这条语句既可以先从表T1里面取出A=1的记录的ID值，再根据ID值关联到表T2，再判断T2里面d的值是否等于2。也可以先从表T2里面取出B=2的记录的ID值，再根据ID值关联到T1，再判断T1里面A的值是否等于1。虽然最终执行的结果是一样的，但是执行效率却有很大的不同。再比如优化器是怎么选择索引的，例子如下：
SELECT C FROM T WHERE A= 'value1' AND B = 'value2';
假设 A上的扫描了 100 个数据行，col2 上扫描 50个数据行，而同时进行的测试只得到了 50个数据行。
先根据A会有100个数据行，接着进行匹配找到其中的 30 个与 B 中的值匹配记录，其中就有 70 次是失败了。
先根据 B会有 50 个数据行，接着进行匹配找到其中的 30 个与 A中的值匹配的记录，只有 20次是失败的，很显然需要的计算和磁盘 I/O 更少。
其结果是，优化器会先选择B索引，因为这样做开销更小。而优化器的作用就是决定选择使用哪一个方案。
因此MySQL 的优化器主要干如下几个重要的事情：
1、选择最合适的索引；
2、选择表扫还是走索引；
3、选择表关联顺序；
4、优化 where 子句；
5、排除管理中无用表；
6、决定 order by 和 group by 是否走索引；
7、尝试使用 inner join 替换 outer join；
8、简化子查询，决定结果缓存；
9、合并试图；
六.执行器
经过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。开始执行的时候，要先判断一下你对这个表T有没有执行查询的权限，如果没有，就会返回没有权限的错误，如下所示。
select * from T where ID=1; ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'
如果有权限，就继续往下执行，这时候执行器就会根据表的引擎定义，去使用这个引擎提供的接口。
这条语句在执行器的执行流程如下：
-
调用InnoDB引擎接口取这个表的第一行，判断ID值是不是1，如果不是则跳过，如果是则将这行存在结果集中；
-
调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
-
执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。
至此，这个语句就执行完成了。对于有索引的表，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的。你会在数据库的慢查询日志中看到一个rows_examined的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。
在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟rows_examined并不是完全相同的。我们后面会专门有一篇文章来讲存储引擎的内部机制，里面会有详细的说明。
三. 实战巩固
执行了这个语句 select * from T where k=1, 必然会报“不存在这个列”的错误： “Unknown column ‘k’ in ‘where clause’”。让我闷想一下这是上面哪个阶段报出来的呢？
答案：很明显是分析器阶段，因为词法分析的时候会解析出查询的表，列等等，所以此时就应该能知道表列的存在性。而且从我个人的拙见来看，如果先一步判断出这种无法查询的错误，避免后续执行，则可以避免无谓的性能开销。而表列的数据较少，完全可以这里判断。