1.准备工作
连接查询至少是要有两个表的，只有一个 single_table 表是不够的，所以为了故事的顺利发展，我们直接构造一个和 single_table 表一模一样的 single_table2 表。为了简便起见，我们把 single_table 表称为 s1 表，把 single_table2 表称为 s2 表。

1.1.Condition filtering介绍
MySQL 中连接查询采用的是嵌套循环连接算法，驱动表会被访问一次，被驱动表可能会被访问多次，所以对于两表连接查询来说，它的查询成本由下边两个部分构成：
(1). 单次查询驱动表的成本
(2). 多次查询被驱动表的成本（具体查询多少次取决于对驱动表查询的结果集中有多少条记录）

我们把对驱动表进行查询后得到的记录条数称之为驱动表的 扇出 （英文名： fanout ）。当查询优化器想计算整个连接查询所使用
的成本时，就需要计算出驱动表的扇出值，有的时候扇出值的计算是很容易的，比如下边这两个查询：
(1). 查询一： SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2;
假设使用 s1 表作为驱动表，很显然对驱动表的单表查询只能使用全表扫描的方式执行，驱动表的扇出值也很明确，那就是驱动表中有多少记录，扇出值就是多少。我们前边说过，统计数据中 s1 表的记录行数是 9693 ，也就是说优化器就直接会把 9693 当作在 s1 表的扇出值。
(2). 查询二： SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.key2 >10 AND s1.key2 < 1000;
仍然假设 s1 表是驱动表的话，很显然对驱动表的单表查询可以使用 idx_key2 索引执行查询。此时 idx_key2 的范围区间 (10, 1000) 中有多少条记录，那么扇出值就是多少。我们前边计算过，满足 idx_key2 的范围区间 (10, 1000) 的记录数是95条，也就是说本查询中优化器会把 95 当作驱动表 s1 的扇出值。

有的时候扇出值的计算就变得很棘手，比方说下边几个查询：
(3). 查询三： SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.common_field > 'xyz';
本查询和 查询一 类似，只不过对于驱动表 s1 多了一个 common_field > 'xyz' 的搜索条件。查询优化器又不会真正的去执行查询，所以它只能 猜 这 9693 记录里有多少条记录满足 common_field > 'xyz' 条件。
(4). 查询四： SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.key2 > 10 AND s1.key2 < 1000 AND s1.common_field > 'xyz';
本查询和 查询二 类似，只不过对于驱动表 s1 也多了一个 common_field > 'xyz' 的搜索条件。不过因为本查询可以使用 idx_key2 索引，所以只需要从符合二级索引范围区间的记录中猜有多少条记录符合 common_field > 'xyz' 条件，也就是只需要猜在 95 条记录中有多少符合 common_field > 'xyz' 条件。
(5). 查询五： SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 WHERE s1.key2 > 10 AND s1.key2 < 1000 AND s1.key1 IN ('a', 'b', 'c') AND s1.common_field > 'xyz';
本查询和 查询二 类似，不过在驱动表 s1 选取 idx_key2 索引执行查询后，优化器需要从符合二级索引范围区间的记录中猜有多少条记录符合下边两个条件：
a. key1 IN ('a', 'b', 'c')
b. common_field > 'xyz'
也就是优化器需要猜在 95 条记录中有多少符合上述两个条件的。

这两种情况下计算驱动表扇出值时需要靠 猜 ：
(1). 如果使用的是全表扫描的方式执行的单表查询，那么计算驱动表扇出时需要猜满足搜索条件的记录到底有多少条。
(2). 如果使用的是索引执行的单表扫描，那么计算驱动表扇出的时候需要猜满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。

设计 MySQL 的大叔把这个 猜 的过程称之为 condition filtering 。

1.2.两表连接的成本分析
连接查询的成本计算公式是这样的：连接查询总成本 = 单次访问驱动表的成本 + 驱动表扇出数 x 单次访问被驱动表的成本
对于左（外）连接和右（外）连接查询来说，它们的驱动表是固定的，所以想要得到最优的查询方案只需要：分别为驱动表和被驱动表选择成本最低的访问方法。

可是对于内连接来说，驱动表和被驱动表的位置是可以互换的，所以需要考虑两个方面的问题：
(1). 不同的表作为驱动表最终的查询成本可能是不同的，也就是需要考虑最优的表连接顺序。
(2). 然后分别为驱动表和被驱动表选择成本最低的访问方法。

下边我们就以内连接为例来看看如何计算出最优的连接查询方案。
比如对于下边这个查询来说：SELECT * FROM single_table AS s1 INNER JOIN single_table2 AS s2 ON s1.key1 = s2.common_field WHERE s1.key2 > 10 AND s1.key2 < 1000 AND s2.key2 > 1000 AND s2.key2 < 2000;

可以选择的连接顺序有两种：
(1). s1 连接 s2 ，也就是 s1 作为驱动表， s2 作为被驱动表。
(2). s2 连接 s1 ，也就是 s2 作为驱动表， s1 作为被驱动表。

查询优化器需要分别考虑这两种情况下的最优查询成本，然后选取那个成本更低的连接顺序以及该连接顺序下各个表的最优访问方法作为最终的查询计划。

(1).使用 s1 作为驱动表的情况：
a. 分析对于驱动表的成本最低的执行方案
首先看一下涉及 s1 表单表的搜索条件有哪些：
a.1. s1.key2 > 10 AND s1.key2 < 1000
所以这个查询可能使用到 idx_key2 索引，从全表扫描和使用 idx_key2 这两个方案中选出成本最低的那个，这个过程我们上边都唠叨过了，很显然使用 idx_key2 执行查询的成本更低些。
b. 然后分析对于被驱动表的成本最低的执行方案
此时涉及被驱动表 idx_key2 的搜索条件就是：
b.1. s2.common_field = 常数（这是因为对驱动表 s1 结果集中的每一条记录，都需要进行一次被驱动表 s2 的访问，此时那些涉及两表的条件现在相当于只涉及被驱动表 s2 了。）
b.2. s2.key2 > 1000 AND s2.key2 < 2000
很显然，第一个条件由于 common_field 没有用到索引，所以并没有什么卵用，此时访问 single_table2 表时可用的方案也是全表扫描和使用 idx_key2 两种，很显然使用 idx_key2 的成本更小。

所以此时使用 single_table 作为驱动表时的总成本就是（暂时不考虑使用 join buffer 对成本的影响）：
使用idx_key2访问s1的成本 + s1的扇出 × 使用idx_key2访问s2的成本

(2). 使用 s2 作为驱动表的情况
a. 分析对于驱动表的成本最低的执行方案
首先看一下涉及 s2 表单表的搜索条件有哪些：
a.1. s2.key2 > 10 AND s2.key2 < 1000
所以这个查询可能使用到 idx_key2 索引，从全表扫描和使用 idx_key2 这两个方案中选出成本最低的那个，这个过程我们上边都唠叨过了，很显然使用 idx_key2 执行查询的成本更低些。
b. 然后分析对于被驱动表的成本最低的执行方案
此时涉及被驱动表 idx_key2 的搜索条件就是：
b.1. s1.key1 = 常数
b.2. s1.key2 > 1000 AND s1.key2 < 2000

使用 idx_key1 可以进行 ref 方式的访问，使用 idx_key2 可以使用 range 方式的访问。这时优化器需要从全表扫描、使用 idx_key1 、使用 idx_key2 这几个方案里选出一个成本最低的方案。这里有个问题啊，因为 idx_key2 的范围区间是确定的： (10, 1000) ，怎么计算使
用 idx_key2 的成本我们上边已经说过了，可是在没有真正执行查询前， s1.key1 = 常数 中的 常数 值我们是不知道的，怎么衡量使用 idx_key1 执行查询的成本呢？其实很简单，直接使用索引统计数据就好了（就是索引列平均一个值重复多少次）。一般情况下， ref 的访问方式要比 range 成本最低，这里假设使用 idx_key1 进行对 s2 的访问。

所以此时使用 single_table 作为驱动表时的总成本就是：
使用idx_key2访问s2的成本 + s2的扇出 × 使用idx_key1访问s1的成本

最后优化器会比较这两种方式的最优访问成本，选取那个成本更低的连接顺序去真正的执行查询。从上边的计算过程也可以看出来，连接查询成本占大头的其实是 驱动表扇出数 x 单次访问被驱动表的成本 ，所以我们的优化重点其实是下边这两个部分：
(1). 尽量减少驱动表的扇出
(2). 对被驱动表的访问成本尽量低

这一点对于我们实际书写连接查询语句时十分有用，我们需要尽量在被驱动表的连接列上建立索引，这样就可以使用 ref 访问方法来降低访问被驱动表的成本了。如果可以，被驱动表的连接列最好是该表的主键或者唯一二级索引列，这样就可以把访问被驱动表的成本降到更低了。

1.3.多表连接的成本分析
首先要考虑一下多表连接时可能产生出多少种连接顺序：
(1). 对于两表连接，比如表A和表B连接
只有 AB、BA这两种连接顺序。其实相当于 2 × 1 = 2 种连接顺序。
(2). 对于三表连接，比如表A、表B、表C进行连接
有ABC、ACB、BAC、BCA、CAB、CBA这么6种连接顺序。其实相当于 3 × 2 × 1 = 6 种连接顺序。
(3). 对于 n 表连接的话，则有 n × (n-1) × (n-2) × ··· × 1 种连接顺序，就是n的阶乘种连接顺序，也就是 n! 。

设计 MySQL 的大叔们想了很多办法减少计算非常多种连接顺序的成本的方法：
(1). 提前结束某种顺序的成本评估
MySQL 在计算各种链接顺序的成本之前，会维护一个全局的变量，这个变量表示当前最小的连接查询成本。如果在分析某个连接顺序的成本时，该成本已经超过当前最小的连接查询成本，那就压根儿不对该连接顺序继续往下分析了。比方说A、B、C三个表进行连接，已经得到连接顺序 ABC 是当前的最小连接成本，比方说 10.0 ，在计算连接顺序 BCA 时，发现 B 和 C 的连接成本就已经大于 10.0 时，就不再继续往后分析 BCA 这个连接顺序的成本了。
(2). 系统变量 optimizer_search_depth
如果连接表的个数小于该值，那么就继续穷举分析每一种连接顺序的成本，否则只对与 optimizer_search_depth 值相同数量的表进行穷举分析。很显然，该值越大，成本分析的越精确，越容易得到好的执行计划，但是消耗的时间也就越长，否则得到不是很好的执行计划，但可以省掉很多分析连接成本的时间。
(3). 根据某些规则压根儿就不考虑某些连接顺序
设计 MySQL 的大叔提出了一些所谓的 启发式规则 （就是根据以往经验指定的一些规则），凡是不满足这些规则的连接顺序压根儿就不分析，这样可以极大的减少需要分析的连接顺序的数量，但是也可能造成错失最优的执行计划。他们提供一个系统变量 optimizer_prune_level 来控制到底是不是用这些启发式规则。

1.4.调节成本常数
我们前边之介绍了两个 成本常数 ：
(1). 读取一个页面花费的成本默认是 1.0
(2). 检测一条记录是否符合搜索条件的成本默认是 0.2

其实除了这两个成本常数， MySQL 还支持好多呢，它们被存储到了 mysql 数据库（这是一个系统数据库，我们之前介绍过）的两个表中：

我们在第一章中就说过，一条语句的执行其实是分为两层的：
(1). server 层
(2). 存储引擎层

在 server 层进行连接管理、查询缓存、语法解析、查询优化等操作，在存储引擎层执行具体的数据存取操作。也就是说一条语句在 server 层中执行的成本是和它操作的表使用的存储引擎是没关系的，所以关于这些操作对应的 成本常数 就存储在了 server_cost 表中，而依赖于存储引擎的一些操作对应的 成本常数 就存储在了 engine_cost 表中。

1.4.1.mysql.server_cost表
server_cost 表中在 server 层进行的一些操作对应的 成本常数 ，具体内容如下：

我们先看一下 server_cost 各个列都分别是什么意思：
(1). cost_name
表示成本常数的名称。
(2). cost_value
表示成本常数对应的值。如果该列的值为 NULL 的话，意味着对应的成本常数会采用默认值。
(3). last_update
表示最后更新记录的时间。
(4). comment
注释。

从 server_cost 中的内容可以看出来，目前在 server 层的一些操作对应的 成本常数 有以下几种：

成本常数名称	默认值	描述
disk_temptable_create_cost	20.0	创建基于磁盘的临时表的成本，如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表。
disk_temptable_row_cost	0.5	向基于磁盘的临时表写入或读取一条记录的成本，如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表。
key_compare_cost	0.05	两条记录做比较操作的成本，多用在排序操作上，如果增大这个值的话会提升 filesort 的成本，让优化器可能更倾向于使用索引完成排序而不是 filesort 。
memory_temptable_create_cost	1.0	创建基于内存的临时表的成本，如果增大这个值的话会让优化器尽量少的创建基于内存的临时表。
memory_temptable_row_cost	0.1	向基于内存的临时表写入或读取一条记录的成本，如果增大这个值的话会让优化器尽量少的创建基于内存的临时表。
row_evaluate_cost	0.1	这个就是我们之前一直使用的检测一条记录是否符合搜索条件的成本，增大这个值可能让优化器更倾向于使用索引而不是直接全表扫描。

MySQL在执行诸如DISTINCT查询、分组查询、Union查询以及某些特殊条件下的排序查询都可能在内部先创建一个临时表，使用这个临时表来辅助完成查询（比如对于DISTINCT查询可以建一个带有UNIQUE索引的临时表，直接把需要去重的记录插入到这个临时表中，插入完成之后的记录就是结果集了）。在数据量大的情况下可能创建基于磁盘的临时表，也就是为该临时表使用MyISAM、InnoDB等存储引擎，在数据量不大时可能创建基于内存的临时表，也就是使用Memory存储引擎。

这些成本常数在 server_cost 中的初始值都是 NULL ，意味着优化器会使用它们的默认值来计算某个操作的成本，如果我们想修改某个成本常数的值的话，需要做两个步骤：
(1). 对我们感兴趣的成本常数做更新操作
比方说我们想把检测一条记录是否符合搜索条件的成本增大到 0.4 ，那么就可以这样写更新语句： UPDATE mysql.server_cost SET cost_value = 0.4 WHERE cost_name = 'row_evaluate_cost';
(2). 让系统重新加载这个表的值。
使用下边语句即可： FLUSH OPTIMIZER_COSTS;

当然，在你修改完某个成本常数后想把它们再改回默认值的话，可以直接把 cost_value 的值设置为 NULL ，再使用 FLUSH OPTIMIZER_COSTS 语句让系统重新加载它就好了。

1.4.2.mysql.engine_cost表
engine_cost表 表中在存储引擎层进行的一些操作对应的 成本常数 ，具体内容如下：

与 server_cost 相比， engine_cost 多了两个列：
(1). engine_name 列
指成本常数适用的存储引擎名称。如果该值为 default ，意味着对应的成本常数适用于所有的存储引擎。
(2). device_type 列
指存储引擎使用的设备类型，这主要是为了区分常规的机械硬盘和固态硬盘，该值默认是 0 。

我们从 engine_cost 表中的内容可以看出来，目前支持的存储引擎成本常数只有两个：

成本常数名称	默认值	描述
io_block_read_cost	1.0	从磁盘上读取一个块对应的成本。请注意我使用的是 块 ，而不是 页 这个词儿。对于InnoDB 存储引擎来说，一个 页 就是一个块，不过对于 MyISAM 存储引擎来说，默认是以 4096 字节作为一个块的。增大这个值会加重 I/O 成本，可能让优化器更倾向于选择使用索引执行查询而不是执行全表扫描。
memory_block_read_cost	0.25	与上一个参数类似，只不过衡量的是从内存中读取一个块对应的成本。

与更新 server_cost 表中的记录一样，我们也可以通过更新 engine_cost 表中的记录来更改关于存储引擎的成本常数，我们也可以通过为 engine_cost 表插入新记录的方式来添加只针对某种存储引擎的成本常数：
(1). 插入针对某个存储引擎的成本常数
比如我们想增大 InnoDB 存储引擎页面 I/O 的成本，书写正常的插入语句即可： INSERT INTO mysql.engine_cost VALUES ('InnoDB', 0, 'io_block_read_cost', 2.0, CURRENT_TIMESTAMP, 'increase Innodb I/O cost');
(2). 让系统重新加载这个表的值。
使用下边语句即可： FLUSH OPTIMIZER_COSTS;