mysql从0到0.1系列：SQL是怎么执行的(上)

select 语句执行流程

流程

创建连接，先连接到数据库，通过连接器连接到客户端（TCP握手链接）此时会获取用户的权限，并且权限获取后，如果修改权限，不会影响当前连接。并且链接的默认有效期是8小时，到期之后会自动断开，默认使用长连接。但是由于长连接内存占用大，会导致mysql内存涨得比较快，导致OOM。目前常见的解决方案是使用连接池。 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的导致连接内存大
查询缓存 建立连接后，进行一个查询请求，会先查询mysql的查询缓存。执行的sql作为key，上次查询的结果作为value。如果缓存命中，则直接返回。如果语句不在查询缓存中，就会继续后面的执行阶段。但是由于缓存的失效条件是只要表上有一次更新，就会淘汰这个表上所有的缓存，所以缓存的命中率会非常低。MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开始彻底没有这个功能了
解析器 如果在查询缓存的步骤中没有查询到缓存（8.0之前），则进行这一步。这里解析器会进行SQL语句的解析，内部将文本格式转换为二进制结构，把关键字解析出来，然后会判断的你的SQL是否符合语法。解析器主要功能有：
- 词法分析(Lexical scanner)：作用是将整个查询分解为多个元素。
- 语法规则(Grammar rule module)：寻找sql语法规则组合，产生一个序列，执行这些规则相关的代码。
经过这两个功能会产生一棵解析树类似于java的词法分析注意这里的解析树不是一般的字节代码，而是C/C++结构 这里不对解析树进行深入讲解，如果想了解可以看这篇博文。

MySQL内核源码解读-SQL解析之解析器浅析

这里会产生一个很多人经常碰到的错误。
```
 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 'xxxxx' at line 1 
```
这个错误就表示，你的SQL存在语法问题。
优化器 优化器算是整个流程中最重要的一个部分，整个SQL的索引选择，JOIN查询的表连接顺序，依靠它来实现。特别是在多索引的环境下，会影响到整个SQL的效率。在下面我会详细的说。
执行器 执行器，顾名思义就是用来真正执行SQL的东西。第一步会先判断你有没有被操作表的权限，如果没有会报错。
```
 ERROR 1142 (42000): SELECT command denied to user 'xx'@'localhost' for table 'xx'
```

如果有权限就会进入表，执行查询语句。而根据优化对于索引的选择不同又有不同的查询逻辑。

优化器是怎么选择索引的

优化器是MySQL比较复杂的一个组件，一条语句在结果相同的情况下一般会有多种执行方式，而优化器则是找到多种执行方式中最优的一个。

查询优化程序有几个目标，但是其主要目标是∶尽可能使用索引，并且使用最严格的索引来消除对行数量随时可能快速增加的顾虑。 ——《MySQL技术内幕》

在这里，我们可以通过这个SQL去查看我们上次查询的成本，它是io_cost和cpu_cost的开销总和

show status like 'Last_query_cost';

结果表示 MySQL的优化器认为大概需要做3.399个数据页的随机查找才能完成上面的查询。

关于这个成本在《高性能MySQL》是这样描述的：每个表或者索引的页面个数、索引的基数（索引中不同值的数量）、索引和数据行的长度、索引分布情况。优化器在评估成本的时候并不考虑任何层面的缓存，它假设读取任何数据都需要一次磁盘 I/O。

这句话可以总结为统计结果仅供参考，会和实际的成本有差别，最直接的就是，InnoDB 因为MVCC 导致每个视图统计的行数不一样，所以成本也会不一样。

我们在实际使用中经常发生这样一种情况，当我们在一个表上有多个索引时，我们期望SQL执行的时候使用 idx_table_a，但是mysql却选择了 idx_table_b。当然这是因为优化器认为使用 idx_table_b比idx_table_a 效果更好，这里就涉及到优化器如何判断一个SQL使用哪个索引最优。

非常建议大家去看看这篇博文，非常考究的做了关于优化器的实验。

MySQL 索引选择原则

文中是基于MySQL 5.5 进行的实验，后面的版本是否有变化待考证。

~~不得不说以前的博文水平很高，现在倒是水分很高(包括我)~~

所有根据上面博文的说法，大概可以分为这几个规则

对无过滤条件、索引可以覆盖的查询。查询优化器选择覆盖索引键值最短的索引进行查询;
对无过滤条件、无索引覆盖的查询。查询优化器选择全表扫描；
对有过滤条件、索引可以覆盖的查询。查询优化器优先基于代价的方式对过滤条件进行处理。如果可以索引查找，将选择代价最低的索引进行查找。如果是全表扫描，则通过查找键值最短的覆盖索引进行查询，并通过过滤条件进行过滤。
对有过滤条件、无索引覆盖的查询。查询优化器基于代价的方式对过滤条件进行处理，生成查询计划。

这里主要代价的就是扫描行数，扫描的行数越少，意味着访问IO次数越少（随机IO），消耗的 CPU 资源越少。当然影响成本的也不止扫描行数，优化器还会结合是否使用临时表、是否排序等因素进行不同的优化流程。可以参考《高性能MYSQL》第六章，这里不展开。

接下来我们来看看扫描行数的问题，其实MySQL并不能准确的知道扫描行数，只能根据基数来判断。

列的基数（cardinality）是指它所容纳的所有非重复值的个数。——《MySql技术内幕》

例如，某个列包含值1，3，7，4，7，3，那么它的基数为4。相对干表里行的总数来说，列的基数越高（也就是说，它包含的唯一值多，重复值少），索引的使用效果越好。

我们可以使用 show index from table 这个SQL去看这个表的基数。

我们这里不妨来做个测试，先创建一张表。

CREATE TABLE `demo`.`test` (
	`id` INT(11) UNSIGNED NOT NULL,
	`a` INT(11) UNSIGNED NULL,
	`b` INT(11) UNSIGNED NULL,
	`c` INT(11) UNSIGNED NULL,
	PRIMARY KEY (`id`),
	KEY `idx_a`(`a`) USING BTREE,
	KEY `idx_b`(`b`) USING BTREE,
	KEY `idx_c`(`c`) USING BTREE
)	ENGINE = InnoDB
	DEFAULT CHARACTER SET = utf8mb4
	COLLATE = utf8mb4_general_ci;