MySQL优化之基础（一）：MySQL架构与SQL执行流程

##1.一条SQL语句的执行流程

###1.1通信协议
我们要执行SQL语句，第一步就是要连接数据库。MySQL数据库本身就是一个运行的服务，监听的默认端口为3306。
我们开发系统跟第三方对接时，必须弄清楚两件事：
a)通信协议，比如用HTTP还是TCP还是WebService;
b)消息格式，比如xml格式，还是JSON格式，还是定长格式，报文头和报文内容是什么，各个字段的含义等；
比如我现在做的某金融商户管理系统，用的JSON报文的消息格式，只要和调用方约定好接口字段即可。
####1.1.1MySQL中的通信协议
Mysql支持多种通信协议，比如同步和异步，长连接和短连接。
按通信类型分为同步和异步：
同步通信特点：a)应用操作数据库，会阻塞线程，等待数据库返回；
b)一般只能做到一对一，很难做到一对多通信；
异步通信特点：a)异步可以避免应用线程阻塞，但是不会减少SQL语句执行的时间；
b)如果异步存在并发，每个SQL的执行都要单独建立一个连接，避免数据混乱。但是这样会给服务端带来巨大的压力，
因为一个连接就要创建一个线程，线程切换会占用大量CPU资源。
c)给编码带来了巨大的复杂性，一般不建议使用，如果要用异步，建议使用连接池，线程排队从连接池中获取连接，而
不是创建新的连接。一般来说，我们数据库用的都是同步。
按连接方式分为长连接和短连接：
短连接就是SQL执行完毕后立即close掉，长连接可以保持打开，减少服务端创建和释放连接的消耗，后面的程序访问的时候还能使用
这个连接，一般我们在连接池中使用的是长连接。
####1.1.2通信方式

单工：在两台计算机之间数据传输只能单向传输。比如遥控器。
半双工：在两台计算机之间，可以相互传输数据，但是同一时间，只能单向传输。比如对讲机。
全双工：在两台计算机之间，同一时间，可以相互传输数据，互不影响。比如打电话。
而在MySQL中使用的是半双工的通信方式。要么是客户端向服务端发送数据，要么是服务端向客户端发送数据，这两个动作
不能同时发生。所以客户端发送 SQL 语句给服务端的时候，（在一次连接里面）数据是不能分成小块发送的，不管你的 SQL
语句有多大，都是一次性发送。
另一方面，对于服务端来说，也是一次性发送所有的数据，不能因为你已经取到了想要的数据就中断操作，这个时候会对网络
和内存产生大量消耗。所以，我们一定要在程序里面避免不带 limit 的这种操作，比如一次把所有满足条件的数据全部查出来，
一定要先 count 一下。如果数据量的话，可以分批查询。
执行一条查询语句，客户端跟服务端建立连接之后呢？下一步要做什么？

###1.2查询缓存
MySQL 内部自带了一个缓存模块。缓存的作用我们应该很清楚了，把数据以 KV 的形式放到内存里面，可以加快数据的读取速度，
也可以减少服务器处理的时间。但是 MySQL 的缓存我们好像比较陌生，从来没有去配置过，也不知道它什么时候生效？
比如 user_innodb 有 500 万行数据，没有索引。我们在没有索引的字段上执行同样的查询，大家觉得第二次会快吗？
缓存没有生效，为什么？MySQL 的缓存默认是关闭的。默认关闭的意思就是不推荐使用，为什么 MySQL 不推荐使用它自带的缓存呢？
主要是因为 MySQL 自带的缓存的应用场景有限，第一个是它要求 SQL 语句必须一模一样，中间多一个空格，字母大小写不同都
被认为是不同的的 SQL。第二个是表里面任何一条数据发生变化的时候，这张表所有缓存都会失效，所以对于有大量数据更新的应用，
也不适合。所以缓存这一块，我们还是交给 ORM 框架（比如 MyBatis 默认开启了一级缓存），或者独立的缓存服务，比如 Redis 来处
理更合适。在 MySQL 8.0 中，查询缓存已经被移除了。
###1.3语法解析和预处理
####1.3.1词法解析
词法解析就是把一个SQL语句打碎成一个个的单词。
####1.3.2语法解析
第二步就是语法分析，语法分析会对 SQL 做一些语法检查，比如单引号有没有闭合，然后根据 MySQL 定义的语法规则，根据 SQL 语句
生成一个数据结构。这个数据结构我们把它叫做解析树（select_lex）。
任何数据库的中间件，比如 Mycat，Sharding-JDBC（用到了 Druid Parser），都必须要有词法和语法分析功能，在市面上也有很多的开
源的词法解析的工具（比如 LEX，Yacc）。
####1.3.3预处理器
解析器可以分析语法，但是它怎么知道数据库里面有什么表，表里面有什么字段呢？实际上还是在解析的时候报错，解析 SQL 的环节
里面有个预处理器。它会检查生成的解析树，解决解析器无法解析的语义。比如，它会检查表和列名是否存在，检查名字和别名，保证
没有歧义。预处理之后得到一个新的解析树。
###1.4查询优化和查询执行计划
####1.4.1什么是优化器？
得到解析树之后，是不是执行 SQL 语句了呢？这里我们有一个问题，一条 SQL 语句是不是只有一种执行方式？或者说数据库最终执行
的 SQL 是不是就是我们发送的 SQL？这个答案是否定的。一条 SQL 语句是可以有很多种执行方式的，最终返回相同的结果，他们是等
价的。但是如果有这么多种执行方式，这些执行方式怎么得到的？最终选择哪一种去执行？根据什么判断标准去选择？这个就是 MySQL
的查询优化器的模块（Optimizer）。查询优化器的目的就是根据解析树生成不同的执行计划（Execution Plan），然后选择一种最优的
执行计划，MySQL 里面使用的是基于开销（cost）的优化器，那种执行计划开销最小，就用哪种。
####1.4.2优化器的作用
MySQL 的优化器能处理哪些优化类型呢？举两个简单的例子：
1、当我们对多张表进行关联查询的时候，以哪个表的数据作为基准表。
2、有多个索引可以使用的时候，选择哪个索引。
实际上，对于每一种数据库来说，优化器的模块都是必不可少的，他们通过复杂的算法实现尽可能优化查询效率的目标。如果对于优化器
的细节感兴趣，可以看看《数据库查询优化器的艺术-原理解析与SQL性能优化》。
####1.4.3优化器得到的结果
优化器最终会把解析树变成一个查询执行计划，查询执行计划是一个数据结构。当然，这个执行计划是不是一定是最优的执行计划呢？
不一定，因为 MySQL 也有可能覆盖不到所有的执行计划。我们怎么查看 MySQL 的执行计划呢？比如多张表关联查询，先查询哪张表？
在执行查询的时候可能用到哪些索引，实际上用到了什么索引？MySQL 提供了一个执行计划的工具。我们在 SQL 语句前面加上 EXPLAIN，
就可以看到执行计划的信息。

###1.5存储引擎
得到执行计划以后，SQL 语句是不是终于可以执行了？问题又来了：
1、从逻辑的角度来说，我们的数据是放在哪里的，或者说放在一个什么结构里面？
2、执行计划在哪里执行？是谁去执行？
####1.5.1存储引擎基本介绍
我们先回答第一个问题：在关系型数据库里面，数据是放在什么结构里面的？
（放在表 Table 里面的）我们可以把这个表理解成 Excel 电子表格的形式。所以我们的表在存储数据的同时，还要组织数据的存储结构，
这个存储结构就是由我们的存储引擎决定的，所以我们也可以把存储引擎叫做表类型。在 MySQL 里面，支持多种存储引擎，他们是
可以替换的，所以叫做插件式的存储引擎。为什么要搞这么多存储引擎呢？一种还不够用吗？
####1.5.2常见的存储引擎
MyISAM 和 InnoDB 是我们用得最多的两个存储引擎，在 MySQL 5.5 版本之前，默认的存储引擎是 MyISAM，它是 MySQL 自带的。
我们创建表的时候不指定存储引擎，它就会使用 MyISAM 作为存储引擎。MyISAM 的前身是 ISAM（Indexed Sequential Access Method：
利用索引，顺序存取数据的方法）。5.5 版本之后默认的存储引擎改成了 InnoDB，它是第三方公司为 MySQL 开发的。为什么要改呢？
最主要的原因还是 InnoDB 支持事务，支持行级别的锁，对于业务一致性要求高的场景来说更适合。
MyISAM （3个文件），特点：适合只读数据分析的项目
a)支持表级别的锁（插入和更新会锁表）。不支持事务。
b)拥有较高的插入（insert）和查询（select）速度。
c)存储了表的行数（count 速度更快）。
InnoDB(2个文件)，特点：适合：经常更新的表，存在并发读写或者有事务处理的业务系统。
a)支持事务，支持外键，因此数据的完整性、一致性更高。
b)支持行级别的锁和表级别的锁。
c)支持读写并发，写不阻塞读（MVCC）。
d)特殊的索引存放方式，可以减少 IO，提升查询效率。
####1.5.3如何选择存储引擎
如果对数据一致性要求比较高，需要事务支持，可以选择 InnoDB。
如果数据查询多更新少，对查询性能要求比较高，可以选择 MyISAM。
如果需要一个用于查询的临时表，可以选择 Memory。
如果所有的存储引擎都不能满足你的需求，并且技术能力足够，可以根据官网内部手册用 C 语言开发一个存储引擎
https://dev.mysql.com/doc/internals/en/custom-engine.html

###1.6执行引擎，返回结果
OK，存储引擎分析完了，它是我们存储数据的形式，继续第二个问题，是谁使用执行计划去操作存储引擎呢？这就是我们的执行引擎，
它利用存储引擎提供的相应的 API 来完成操作。为什么我们修改了表的存储引擎，操作方式不需要做任何改变？因为不同功能的存储引
擎实现的 API 是相同的。最后把数据返回给客户端，即使没有结果也要返回。