执行如下 SQL，我们看到的只是输入一条语句，返回一个结果，却不知道这条语句在 MySQL 内部的执行过程。
select * from where id ='1';
上图给出的是 MySQL 的基本架构示意图，从中你可以清楚地看到 SQL 语句在 MySQL 的各个功能模块中的执行过程。大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。
Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。
而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。也可以通过指定存储引擎的类型来选择别的引擎，比如在 create table 语句中使用 engine=memory, 来指定使用内存引擎创建表。
一条 SQL 查询的完整执行流程如上图所示。
Server 服务层
连接器
连接数据库最开始肯定是连接器。连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般是这么写的：
mysql -h$ip -P$port -u$user -p输完命令之后，你就需要在交互对话里面输入密码。虽然密码也可以直接跟在 -p 后面写在命令行中，但这样可能会导致你的密码泄露。如果你连的是生产服务器，强烈建议你不要这么做。
连接命令中的 mysql 是客户端工具，用来跟服务端建立连接。在完成经典的 TCP 握手后，连接器就要开始认证你的身份，这个时候用的就是你输入的用户名和密码。
- 如果用户名或密码不对，你就会收到一个 "Access denied for user" 的错误，然后客户端程序结束执行。
- 如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。
这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。
连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。文本中这个图是 show processlist 的结果，其中的 Command 列显示为 “Sleep” 的这一行，就表示现在系统里面有一个空闲连接。
客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。
如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了。
数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。
建立连接的过程通常是比较复杂的，所以我建议你在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。但是全部使用长连接后，你可能会发现，有些时候 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。
怎么解决这个问题呢？你可以考虑以下两种方案。
查询缓存
连接建立完成后，你就可以执行 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 开始彻底没有这个功能了。
分析器
如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要对 SQL 语句做解析。
分析器先会做 “词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。
MySQL 从你输入的 "select" 这个关键字识别出来，这是一个查询语句。它也要把字符串 “T” 识别成 “表名 T”，把字符串 “ID” 识别成 “列 ID”。
做完了这些识别以后，就要做 “语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。
如果你的语句不对，就会收到 “You have an error in your SQL syntax” 的错误提醒，比如下面这个语句 select 少打了开头的字母 “s”。
mysql> elect * from t where ID=1;
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” 的内容。
优化器
经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。
优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。通常两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。
执行 SQL 查询的时候优化器主要执行如下任务：
MySQL 查询优化器有几个目标，但是其中最主要的目标是尽可能地使用索引，并且使用最严格的索引来消除尽可能多的数据行。
优化器试图排除数据行的原因在于它排除数据行的速度越快，那么找到与条件匹配的数据行也就越快。如果能够首先进行最严格的测试，查询就可以执行地更快。
执行器
MySQL 通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。 开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误，如下所示 (在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。查询也会在优化器之前调用 precheck 验证权限)。
mysql> select * from T where ID=10;
ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。 比如我们这个例子中的表 T 中，ID 字段没有索引，那么执行器的执行流程是这样的：
至此，这个语句就执行完成了。
对于有索引的表，执行的逻辑也差不多。第一次调用的是 “取满足条件的第一行” 这个接口，之后循环取 “满足条件的下一行” 这个接口，这些接口都是引擎中已经定义好的。
你会在数据库的慢查询日志中看到一个 rows_examined 的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。
在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟 rows_examined 并不是完全相同的。
存储引擎
通过 show engines; 查看引擎类型，可以看出来要用到事务只能用 InnoDB 引擎类型。
InnoDB 存储引擎
InnoDB 是 MySQL 的默认事务型引擎，也是最重要、使用最广泛的存储引擎，并且有行级锁定和外键约束。它被设计用来处理大量的短期 (short-lived) 事务，短期事务大部分情况是正常提交，很少会被回滚。InnoDB 的性能和自动崩溃恢复特性，使得它在非事务型存储的需求中也很流行。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑 InnoDB 引擎。
InnoDB 的适用场景 / 特性，有以下几种：
- 经常更新的表，适合处理多重并发的更新请求。
- 支持事务。
- 可以从灾难中恢复（通过 bin-log 日志等）。
- 外键约束。只有他支持外键。
- 支持自动增加列属性 auto_increment。
MyISAM 存储引擎
MyISAM 提供了大量的特性，包括全文检索、压缩等，但不支持事务和行级锁，支持表级锁。 对于只读的数据，或者表较小、可以忍受修复操作的场景，依然可以使用 MyISAM。
MyISAM 的适用场景 / 特性，有以下几种：
- 不支持事务的设计，但是并不代表着有事务操作的项目不能用 MyISAM 存储引擎，完全可以在程序层进行根据自己的业务需求进行相应的控制。
- 不支持外键的表设计。
- 查询速度很快，如果数据库 insert 和 update 的操作比较多的话比较适用。
- 整天 对表进行加锁的场景。
- MyISAM 极度强调快速读取操作。
- MyIASM 中存储了表的行数，于是 SELECT COUNT (*) FROM TABLE 时只需要直接读取已经保存好的值而不需要进行全表扫描。如果表的读操作远远多于写操作且不需要数据库事务的支持，那么 MyIASM 也是很好的选择。
MySQL 内建的其他存储引擎
MySQL 还有一些特殊用途的存储引擎，在一些特殊场景下用起来会很爽的。在 MySQL 新版本中，有些可能因为一些原因已经不再支持了，还有一些会继续支持，但是需要明确地启用后才能使用。
Archive 存储引擎
Archive 引擎只支持 insert 和 select 操作，并且在 MySQL 5.1 之前连索引都不支持。
Archive 引擎会缓存所有的写并利用 zlib 对插入的行进行压缩，所以比 MyISAM 引擎的磁盘 I/O 更少。但是每次 select 查询都需要进行全表扫描，所以 Archive 更适合日志和数据采集类应用，况且这类应用在做数据分析时往往需要全表扫描。
Archive 引擎支持行级锁和专用的缓冲区，所以可以实现高并发的插入。在一个查询开始直到返回表中存在的所有行之前，Archive 引擎会阻止其他的 select 执行，以实现一致性读。另外，这也实现了批量插入在完成之前对读操作是不看见的。
Blackhole 存储引擎
Blackhole 引擎没有实现任何的存储机制，它会丢失所有插入的数据，不做任何保存。怪哉，岂不是一无用处？但是服务器会记录 Blackhole 的日志，所以可以用于复制数据到备库，或者只是简单地记录到日志。这种特殊的存储引擎可以在一些特殊的复制架构和日志审核时发挥作用。
但这种存储引擎的存在，至今还是有些难以理解。
CSV 存储引擎
CSV 引擎可以将普通的 CSV 文件作为 MySQL 的表来处理，但这种表不支持索引。
CSV 引擎可以在数据库运行时拷入或者拷出文件，可以将 Excel 等电子表格软件中的数据存储为 CSV 文件，然后复制到 MySQL 数据目录下，就能在 MySQL 中打开使用。同样，如果将数据写入到一个 CSV 引擎表中，其他的外部程序也能立即从表的数据文件中读取 CSV 格式的数据。
因此，CSV 引擎可以作为一种数据交换的机制，是非常有用的。
Memory 存储引擎
如果需要快速地访问数据，并且这些数据不会被修改，重启以后丢失也没有关系，那么使用 Memory 引擎是非常有用的。Memory 引擎至少比 MyISAM 引擎要快一个数量级，因为所有的数据都保存在内存中，不需要进行磁盘 I/O。Memory 引擎的表结构在重启以后还会保留，但数据会丢失。
Memory 引擎在很多场景下可以发挥很好的作用：
- 用于查找或者映射表，例如将邮箱和州名映射的表。
- 用于缓存周期性聚合数据的结果。
- 用于保存数据分析中产生的中间数据。
Memory 引擎支持 Hash 索引，因此查找非常快。虽然 Memory 的速度非常快，但还是无法取代传统的基于磁盘的表。Memory 引擎是表级锁，因此并发吸入的性能较低。
如果 MySQL 在执行查询的过程中，需要使用临时表来保存中间结果，内部使用的临时表就是 Memory 引擎。如果中间结果太大超出了 Memory 的限制，或者含有 BLOB 或 TEXT 字段，则临时表会转换成 MyISAM 的引擎。
看了上面的说明，大家就会经常混淆 Memory 和临时表了。临时表是指使用 CREATE TEMPORARY TABLE 语句创建的表，它可以使用任何存储引擎，因此和 Memory 不是一回事。临时表只在单个连接中可见，当连接断开时，临时表也将不复存在。
关于临时表和 Memory 引擎的那些事，可参考 MySQL・引擎特性・临时表那些事儿。
MySQL 的存储引擎及第三方存储引擎，还有很多，在此就不一一介绍了，后续如有需要，再进一步来谈谈。
如何选择合适的存储引擎呢
这么多存储引擎，真是眼花缭乱，我们该如何选择呢？
大部分情况下，都会选择默认的存储引擎 ——InnoDB，并且这也是最正确的选择，所以 Oracle 在 MySQL 5.5 版本时终于将 InnoDB 作为默认的存储引擎了。
对于如何选择合适的存储引擎，可以简单地归纳为一句话：” 除非需要用到某些 InnoDB 不具备的特性，并且没有其他可以替代，否则都应该优先选择 InnoDB 引擎”。
例如，如果要用到全文检索，建议优先考虑 InnoDB 加上 Sphinx 的组合，而不是使用支持全文检索的 MyISAM。当然，如果不需要用到 InnoDB 的特性，同时其他引擎的特性能够更好地满足需求，就可以考虑一下其他存储引擎。 除非万不得已，建议不要混合使用多种存储引擎，否则可能带来一系列复杂的问题，以及一些潜在的 bug 和边界问题。
如果需要使用不同的存储引擎，建议考虑从以下几个因素进行衡量考虑。
- 事务
- 备份
- 恢复
- 特有的特性
其他查找引擎 SQL
通过下面的命令查看默认的存储引擎。
mysql> show variables like '%storage_engine%';
--查看表的存储引擎
show table status like "table_name" ;本文分享自华为云社区《一条查询 SQL 是如何执行的》，作者： 共饮一杯无 。
