MySQL Select语句是如何执行的

MySQL Select语句是怎么执行的？

   最近在极客时间看丁奇大佬的《MySQL45讲》，真心觉得讲的不错，把其中获得的一些MySQL方向的经验整理整理分享给大家，有兴趣同学可以购买相关课程进行学习。

   今天分享的内容是select和update的执行流程。

select的执行过程

话不多说，来个神图镇楼(自己画的)。

   首先，我们可以看到，整个select语句包含三个模块，其中客户端和MySQL两个部分，MySQL又包含server端和存储引擎侧，server端包含连接器、查询缓存、分析器、优化器，执行器等多个部分，存储引擎侧同样包含innodb、Myisam，memory等多种存储引擎。

每个模块的作用如下：

连接器：

   连接器的任务是跟客户端建立连接，查询权限，维持和管理连接等等。当我们使用命令行登录时，如果密码或者账号错误，那么连接器会返回给我们Access Deny的报错，利用正确的账号密码登录到MySQL之后，连接器会查询当前账号的登录权限，之后的所有操作，都是依赖这个权限进行的。

注意，如果此时我们更改了该账号的权限，并不会对已经存在的连接产生影响，而只对新加入的连接产生影响。

   如果客户端连接进入MySQL后，一直没有进行任何操作，那么连接器将会在wait_timeout参数设置的时间后，将该连接断开。建议在程序中使用长连接，这样可以减小和客户端和MySQL建立连接的带来的性能损耗。

查询缓存：

当客户端输入一个SQL之后，如果命中查询缓存，那么MySQL将会直接返回结果，而不进行下面的一系列分析操作，如果没有命中，则开始进入分析器---优化器---执行器这个流程。关于查询缓存，还有2点需要注意：

a、MySQL8.0中开始弃用查询缓存，因为查询缓存的命中率一般较低，弊大于利。

b、在高并发场景中，建议将查询缓存关闭，关闭时使用query_cache_type=off或者query_cache_size=0。

c、如果非要使用这个功能，可以将参数query_cache_type设置成DEMAND，这样，就可以使用select sql_cache  * from table这种方式强制使用查询缓存的功能了。

分析器：

如果我们的查询没有真正命中查询缓存，那么就要进入分析器这个环节了，分析器的主要功能是词法分析和语法分析，其中：

词法分析指的是根据SQL分析出来select、update、alter、列名、表名、库名等；

语法分析是指需要分析你写的SQL是否满足MySQL的语法。如果不满足，则会给出you have an error xxx的提示。

优化器：

   优化器的作用是选出SQL执行的最佳路径，例如在多表join的时候，优化器会选择最高效的方案来执行连接查询。这里可以给出一个例子，例如我们建立了(a,b)的联合索引，

select * from table where a=1 and b=1；

select * from table where b=1 and a=1；

这两条SQL是等价的，因为优化器会将下面的改造成上面的样子，从而应用联合索引进行搜索查询。

执行器：

  SQL经过优化器之后，就会进入执行器，执行SQL前，需要校验表的权限，如果有权限，会根据表的存储引擎定义，去使用这个存储引擎提供的接口，最终将数据返回给客户端，并开始等待新的连接。

这里需要注意一点：执行器调用一次，在引擎内部则扫描了多行，因此存储引擎扫描行数跟rows_examined并不是完全相同的。

Q && A

Q1：为什么对权限的检查不在优化器之前做？

A1：有些时候，SQL语句要操作的表不只是SQL字面上那些。比如如果有个触发器，得在执行器阶段（过程中）才能确定。优化器阶段前是无能为力的

Q2：MySQL权限到底在哪里验证？

A2：账号的登录权限在连接器模块验证；表的操作权限分为两种情况，如果命中查询缓存，会在查询缓存放回结果的时候验证，在优化器之前，如果没有命中索引，则权限验证在执行器模块验证。