MySQL的执行流程
MySQL架构
MySQL分为Sever层和存储引擎层
Server层负责建立连接、分析和执行SQL
- 连接器、查询缓存、解析器、预处理器、优化器、执行器
- 内置函数：日期、事件、数学、加密函数
- 跨存储引擎的功能：存储过程、触发器、视图
存储引擎负责数据的存储和提取
- InnoDB（5.5版本开始默认引擎）
- MyISAM
- Memory
我们常说的索引数据结构，就是由存储引擎层实现的，不同的存储引擎支持的索引类型也不相同，比如 InnoDB 支持索引类型是 B+树 ，且是默认使用，也就是说在数据表中创建的主键索引和二级索引默认使用的是 B+ 树索引。
连接器
- 建立连接（TCP三次握手、四次挥手）
- 管理连接
- 校验用户身份
如果一个用户已经建立了连接，即使管理员中途修改了该用户的权限，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。
查询缓存
如果 SQL 是查询语句（select 语句），MySQL 就会先去查询缓存（ Query Cache ）里查找缓存数据，看看之前有没有执行过这一条命令，这个查询缓存是以 key-value 形式保存在内存中的，key 为 SQL 查询语句，value 为 SQL 语句查询的结果。
如果查询的语句命中查询缓存，那么就会直接返回 value 给客户端。如果查询的语句没有命中查询缓存中，那么就要往下继续执行，等执行完后，查询的结果就会被存入查询缓存中。
MySQL 8.0 版本直接将查询缓存删掉了，也就是说 MySQL 8.0 开始，执行一条 SQL 查询语句，不会再走到查询缓存这个阶段了。对于 MySQL 8.0 之前的版本，如果想关闭查询缓存，我们可以通过将参数 query_cache_type 设置成 DEMAND。
解析SQL
解析器
-
词法分析，构建出 SQL 语法树
-
语法分析，判断 SQL 语句是否满足 MySQL 语法（关键字拼写错误）
执行SQL
预处理器
- 检查 SQL 查询语句中的表或者字段是否存在（不存在报错）；
- 将
select *中的*符号，扩展为表上的所有列；
优化器
优化器主要负责将 SQL 查询语句的执行方案确定下来，比如在表里面有多个索引的时候，优化器会基于查询成本的考虑，来决定选择使用哪个索引。
主键索引
- 属于聚簇索引，索引和数据一块储存
- InnoDB只有主键索引才能是聚簇索引
所谓的聚簇索引，就是一个节点就是整个的一行数据。我们平常见到的二叉树数据结构像这样
struct TreeNode {
int val;
TreeNode *left;
TreeNode *right;
TreeNode() : val(0), left(nullptr), right(nullptr) {}
TreeNode(int x) : val(x), left(nullptr), right(nullptr) {}
TreeNode(int x, TreeNode *left, TreeNode *right) : val(x), left(left), right(right) {}
};
数据结构中只有左右指针和当前节点的值，可以根据节点的值建立二叉搜索树。代入到聚簇索引的定义中，根据主键建立B+树，就像二叉搜索树左孩子val小于自己，右孩子大于自己。数据结构储存更多的东西，把表中一行的所有内容都作为成员变量存起来。找到了主键的节点，也就找到了这一行的所有数据。
非聚簇索引则是使用索引项建立B+树，例如根据年龄、名字等，节点里面则储存着对应行的主键。比如我要查询年龄大于21岁的人，并且年龄这一列拥有索引（显然应该是非聚簇的，因为年龄可能重复）。抽象地，我们认为把年龄进行了排序，我们仅能看到一群年龄从小到大，而不知道这些人是谁。我们把大于21岁人拉过来，挨个撕开他们的面纱，也就是他们的主键，才知道是谁。非聚簇索引只储存主键，如果要查询那一行的其他信息，则要根据主键再进行查询，也就是用上面的那个聚簇索引，找到了主键就找到了那一行的所有值。这称为回表查询。
非聚簇索引不一定进行回表查询。覆盖索引即需要查询的字段正好是索引的字段，那么直接根据该索引，就可以查到数据了， 而无需回表查询。
用户准备使用 SQL 查询用户名，而用户名字段正好建立了索引。那么这个索引的 key 本身就是 name，查到对应的 name 直接返回就行了，无需回表查询。（是不是很神奇？这不废话吗
二级索引
二级索引又称为辅助索引，是因为二级索引的叶子节点存储的数据是主键。也就是说，通过二级索引，可以定位主键的位置。二级索引都是非聚簇索引。
- 唯一索引(Unique Key)
- 普通索引(Index)
- 前缀索引(Prefix)
回到优化器，举一个例子：
select id from product where id > 1 and name like 'i%';
product 表有主键索引（id）和普通索引（name）。这条查询语句的结果既可以使用主键索引，也可以使用普通索引，但是执行的效率会不同。这时，就需要优化器来决定使用哪个索引了。
很显然这条查询语句是覆盖索引，直接在二级索引就能查找到结果（因为二级索引的 B+ 树的叶子节点的数据存储的是主键值），就没必要在主键索引查找了，因为查询主键索引的 B+ 树的成本会比查询二级索引的 B+ 的成本大，优化器基于查询成本的考虑，会选择查询代价小的普通索引。
执行器
在执行的过程中，执行器和存储引擎交互，交互是以记录为单位的。
- 主键索引查询
select * from product where id = 1;
存储引擎通过主键索引的 B+ 树结构定位到 id = 1的第一条记录，如果记录是不存在的，就会向执行器上报记录找不到的错误，然后查询结束。如果记录是存在的，就会将记录返回给执行器；
执行器从存储引擎读到记录后，接着判断记录是否符合查询条件（其他查询条件，这一步只是满足了主键的条件），如果符合则发送给客户端，如果不符合则跳过该记录。
- 全表扫描
存储引擎把一条记录取出后就将其返回给执行器（Server层），执行器继续判断条件，不符合查询条件即跳过该记录，否则发送到客户端；
Server 层每从存储引擎读到一条记录就会发送给客户端，之所以客户端显示的时候是直接显示所有记录的，是因为客户端是等查询语句查询完成后，才会显示出所有的记录
- 索引下推
MySQL 5.6 推出的查询优化策略。索引下推能够减少二级索引在查询时的回表操作，提高查询的效率，因为它将 Server 层部分负责的事情，交给存储引擎层去处理了。
select * from t_user where age > 20 and reward = 100000;
联合索引当遇到范围查询 (>、<) 就会停止匹配，也就是 age 字段能用到联合索引，但是 reward 字段则无法利用到索引。
那么，不使用索引下推（MySQL 5.6 之前的版本）时，执行器与存储引擎的执行流程是这样的：
- Server 层首先调用存储引擎的接口定位到满足查询条件的第一条二级索引记录，也就是定位到 age > 20 的第一条记录；
- 存储引擎根据二级索引的 B+ 树快速定位到这条记录后，获取主键值，然后进行回表操作，将完整的记录返回给 Server 层；
- Server 层在判断该记录的 reward 是否等于 100000，如果成立则将其发送给客户端；否则跳过该记录；
- 接着，继续向存储引擎索要下一条记录，存储引擎在二级索引定位到记录后，获取主键值，然后回表操作，将完整的记录返回给 Server 层；
- 如此往复，直到存储引擎把表中的所有记录读完。
可以看到，没有索引下推的时候，每查询到一条二级索引记录，都要进行回表操作，然后将记录返回给 Server，接着 Server 再判断该记录的 reward 是否等于 100000。
而使用索引下推后，判断记录的 reward 是否等于 100000 的工作交给了存储引擎层，过程如下 ：
- Server 层首先调用存储引擎的接口定位到满足查询条件的第一条二级索引记录，也就是定位到 age > 20 的第一条记录；
- 存储引擎定位到二级索引后，先不执行回表操作，而是先判断一下该索引中包含的列（reward列）的条件（reward 是否等于 100000）是否成立。如果条件不成立，则直接跳过该二级索引。如果成立，则执行回表操作，将完成记录返回给 Server 层。
- Server 层在判断其他的查询条件（本次查询没有其他条件）是否成立，如果成立则将其发送给客户端；否则跳过该记录，然后向存储引擎索要下一条记录。
- 如此往复，直到存储引擎把表中的所有记录读完。
可以看到，使用了索引下推后，虽然 reward 列无法使用到联合索引，但是因为它包含在联合索引（age，reward）里，所以直接在存储引擎过滤出满足 reward = 100000 的记录后，才去执行回表操作获取整个记录。相比于没有使用索引下推，节省了很多回表操作。
参考文章：
执行一条 select 语句，期间发生了什么？ | 小林coding
MySQL的二级索引 - 乐子不痞 - 博客园
