MySQL执行一个查询可以有不同的执行方案，它会选择其中成本最低的方案。MySQL中一条查询语句的执行成本是由下边这两个方面组成的：
I/O成本
MyISAM、InnoDB存储引擎都是将数据和索引都存储到磁盘上的，当查询表中的记录时，需要先把数据或者索引加载到内存中然后再操作。这个从磁盘到内存这个加载的过程损耗的时间称之为I/O成本
CPU成本
读取以及检测记录是否满足对应的搜索条件、对结果集进行排序等这些操作损耗的时间称之为CPU成本。
对于InnoDB存储引擎来说，页是磁盘和内存之间交互的基本单位，读取一个页面花费的成本默认是1.0，读取以及检测一条记录是否符合搜索条件的成本默认是0.2，不管读取记录时需不需要检测是否满足搜索条件，其成本都算是0.2。 1.0、0.2这些数字称之为成本常数，成本常数可以调整，成本常数不止有这两个
成本常数存储在系统数据库mysql中，通过语句：
SHOW TABLES FROM mysql LIKE '%cost%';
可以看到：
| Tables_in_mysql (%cost%) |
|---|
| engine_cost |
| server_cost |
MySQL可以分为两层：
在服务器层进行连接管理、查询缓存、语法解析、查询优化等操作，在存储引擎层执行具体的数据存取操作。 一条语句在server层中执行的成本是和它操作的表使用的存储引擎是没关系的，所以关于这些操作对应的成本常数就存储在了server_cost表中， 而依赖于存储引擎的一些操作对应的成本常数就存储在了engine_cost表中
server_cost表中成本常数，可以通过下面查询语句：
SELECT * FROM mysql.server_cost;
查询结果为：
+------------------------------+------------+---------------------+---------+
| cost_name | cost_value | last_update | comment |
+------------------------------+------------+---------------------+---------+
| disk_temptable_create_cost | NULL | 2018-01-20 12:03:21 | NULL |
| disk_temptable_row_cost | NULL | 2018-01-20 12:03:21 | NULL |
| key_compare_cost | NULL | 2018-01-20 12:03:21 | NULL |
| memory_temptable_create_cost | NULL | 2018-01-20 12:03:21 | NULL |
| memory_temptable_row_cost | NULL | 2018-01-20 12:03:21 | NULL |
| row_evaluate_cost | NULL | 2018-01-20 12:03:21 | NULL |
+------------------------------+------------+---------------------+---------+
cost_name
表示成本常数的名称
cost_value
表示成本常数对应的值。如果该列的值为NULL，则对应的成本常数会采用默认值
各种成本：
| 成本常数名称 | 默认值 | 描述 |
|---|---|---|
| disk_temptable_create_cost | 40.0 | 创建基于磁盘的临时表的成本，如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表 |
| disk_temptable_row_cost | 1.0 | 向基于磁盘的临时表写入或读取一条记录的成本，如果增大这个值的话会让优化器尽量少的创建基于磁盘的临时表 |
| key_compare_cost | 0.1 | 两条记录做比较操作的成本，多用在排序操作上，如果增大这个值的话会提升filesort的成本，让优化器可能更倾向于使用索引完成排序而不是filesort |
| memory_temptable_create_cost | 2.0 | 创建基于内存的临时表的成本，如果增大这个值的话会让优化器尽量少的创建基于内存的临时表 |
| memory_temptable_row_cost | 0.2 | 向基于内存的临时表写入或读取一条记录的成本，如果增大这个值的话会让优化器尽量少的创建基于内存的临时表 |
| row_evaluate_cost | 0.2 | 这个就是上面提到的检测一条记录是否符合搜索条件的成本，增大这个值可能让优化器更倾向于使用索引而不是直接全表扫描 |
MySQL在执行诸如DISTINCT查询、分组查询、Union查询以及某些特殊条件下的排序查询都可能在内部先创建一个临时表， 使用这个临时表来辅助完成查询（比如对于DISTINCT查询可以建一个带有UNIQUE索引的临时表，直接把需要去重的记录插入到这个临时表中，插入完成之后的记录就是结果集了）。 在数据量大的情况下可能创建基于磁盘的临时表，也就是为该临时表使用MyISAM、InnoDB等存储引擎，在数据量不大时可能创建基于内存的临时表，也就是使用Memory存储引擎。
创建临时表和对这个临时表进行写入和读取的操作代价是很高的
调整成本常数分两个步骤：
设置值
例如：
UPDATE mysql.server_cost SET cost_value = 0.4 WHERE cost_name = 'row_evaluate_cost';
恢复默认值：
UPDATE mysql.server_cost SET cost_value = NULL WHERE cost_name = 'row_evaluate_cost';
重新加载
重新加载这个值：
FLUSH OPTIMIZER_COSTS;
engine_cost表中成本常数，可以通过下面查询语句：
SELECT * FROM mysql.engine_cost;
查询结果为：
+-------------+-------------+------------------------+------------+---------------------+---------+
| engine_name | device_type | cost_name | cost_value | last_update | comment |
+-------------+-------------+------------------------+------------+---------------------+---------+
| default | 0 | io_block_read_cost | NULL | 2018-01-20 12:03:21 | NULL |
| default | 0 | memory_block_read_cost | NULL | 2018-01-20 12:03:21 | NULL |
+-------------+-------------+------------------------+------------+---------------------+---------+
engine_name
指成本常数适用的存储引擎名称。如果该值为default，意味着对应的成本常数适用于所有的存储引擎
device_type
指存储引擎使用的设备类型，这主要是为了区分常规的机械硬盘和固态硬盘，不过在MySQL 5.7.21这个版本中并没有对机械硬盘的成本和固态硬盘的成本作区分，所以该值默认是0
| 成本常数名称 | 默认值 | 描述 |
|---|---|---|
| io_block_read_cost | 1.0 | 从磁盘上读取一个块对应的成本。对于InnoDB存储引擎来说，一个页就是一个块，不过对于MyISAM存储引擎来说，默认是以4096字节作为一个块的。增大这个值会加重I/O成本，可能让优化器更倾向于选择使用索引执行查询而不是执行全表扫描。 |
| memory_block_read_cost | 1.0 | 与上一个参数类似，只不过衡量的是从内存中读取一个块对应的成本。 |
调整、插入存储引擎的成本常数：
插入针对某个存储引擎的成本常数
增大InnoDB存储引擎页面I/O的成本：
INSERT INTO mysql.engine_cost VALUES ('InnoDB', 0, 'io_block_read_cost', 2.0,CURRENT_TIMESTAMP, 'increase Innodb I/O cost');
让系统重新加载这个表的值
与上面一样：
FLUSH OPTIMIZER_COSTS;
引用上章数据库表：
CREATE TABLE single_table (
id INT NOT NULL AUTO_INCREMENT,
key1 VARCHAR(100),
key2 INT,
key3 VARCHAR(100),
key_part1 VARCHAR(100),
key_part2 VARCHAR(100),
key_part3 VARCHAR(100),
common_field VARCHAR(100),
PRIMARY KEY (id),
KEY idx_key1 (key1),
UNIQUE KEY idx_key2 (key2),
KEY idx_key3 (key3),
KEY idx_key_part(key_part1, key_part2, key_part3)
) Engine=InnoDB CHARSET=utf8mb4;
向表中插入10000条值随机的记录。在一条单表查询语句真正执行之前，MySQL的查询优化器会找出执行该语句所有可能使用的方案， 对比之后找出成本最低的方案，这个成本最低的方案就是执行计划，之后才会调用存储引擎提供的接口真正的执行查询，这个过程总结一下就是这样：
假设查询语句如下：
SELECT * FROM single_table WHERE key1 IN ('a', 'b', 'c') AND key2 > 10 AND key2 < 1000 AND key3 > key2 AND key_part1 LIKE '%hello%' AND common_field = '123';
对于B+树索引来说，只要索引列和常数使用=、<=>、IN、NOT IN、IS NULL、IS NOT NULL、>、<、>=、<=、BETWEEN、!=（不等于也可以写成<>）或者LIKE操作符连接起来，就可以产生一个所谓的范围区间（LIKE匹配字符串前缀也行）， 也就是说这些搜索条件都可能使用到索引，那么把一个查询中可能使用到的索引称之为possible keys
条件语句中的几个搜索条件：
上边的查询语句可能用到的索引possible keys只有idx_key1和idx_key2
对于InnoDB存储引擎来说，全表扫描的意思就是把聚簇索引中的记录都依次和给定的搜索条件做一下比较，把符合搜索条件的记录加入到结果集， 所以需要将聚簇索引对应的页面加载到内存中，然后再检测记录是否符合搜索条件。由于查询成本=I/O成本+CPU成本，所以计算全表扫描的代价需要两个信息：
MySQL为每个表维护了一系列的统计信息，而上面这两个信息就属于统计信息，查看表的统计信息：
SHOW TABLE STATUS table_name;
那么我们创建的表single_table统计信息:
SHOW TABLE STATUS LIKE 'single_table'\G
结果为：
Name: single_table
Engine: InnoDB
Version: 10
Row_format: Dynamic
Rows: 9693
Avg_row_length: 163
Data_length: 1589248
Max_data_length: 0
Index_length: 2752512
Data_free: 4194304
Auto_increment: 10001
Create_time: 2019-11-26 11:45:05
Update_time: 2019-11-26 11:55:11
Check_time: NULL
Collation: utf8mb4_general_ci
Checksum: NULL
Create_options:
Comment:
Rows
本选项表示表中的记录条数。对于使用MyISAM存储引擎的表来说，该值是准确的，对于使用InnoDB存储引擎的表来说， 该值是一个估计值。从查询结果我们也可以看出来
从创建表语句看出single_table表是使用InnoDB存储引擎的，虽然实际上表中有10000条记录，但是SHOW TABLE STATUS显示的Rows值只有9693条记录
Data_length
本选项表示表占用的存储空间字节数。使用MyISAM存储引擎的表来说，该值就是数据文件的大小，对于使用InnoDB存储引擎的表来说，该值就相当于聚簇索引占用的存储空间大小，也就是说可以这样计算该值的大小：
Data_length = 聚簇索引的页面数量 x 每个页面的大小
而上边查询结果显示Data_length的值是1589248，所以我们可以推算出聚簇索引的页面数量：
聚簇索引的页面数量 = 1589248 ÷ 16 ÷ 1024 = 97
我们现在已经得到了聚簇索引占用的页面数量以及该表记录数的估计值，所以就可以计算全表扫描成本了，在真实计算成本时增加了微调值，这些微调的值是直接硬编码到代码里的， 现在可以看一下全表扫描成本的计算过程：
I/O成本：97 x 1.0 + 1.1 = 98.1
97指的是聚簇索引占用的页面数，1.0指的是加载一个页面的成本常数，后边的1.1是一个微调值
CPU成本：9693 x 0.2 + 1.0 = 1939.6
9693指的是统计数据中表的记录数，对于InnoDB存储引擎来说是一个估计值，0.2指的是访问一条记录所需的成本常数，后边的1.0是一个微调值
总成本：98.1 + 1939.6 = 2037.7
综上所述，对于single_table的全表扫描所需的总成本就是2037.7。我们知道表中的记录其实都存储在聚簇索引对应B+树的叶子节点中， 所以只要通过根节点获得了最左边的叶子节点，就可以沿着叶子节点组成的双向链表把所有记录都查看一遍。也就是说全表扫描这个过程其实有的B+树内节点是不需要访问的， 但是在计算全表扫描成本时直接使用聚簇索引占用的页面数作为计算I/O成本的依据，是不区分内节点和叶子节点的
从第1步分析我们得到，上述查询可能使用到idx_key1和idx_key2这两个索引，我们需要分别分析单独使用这些索引执行查询的成本，最后还要分析是否可能使用到索引合并。这里需要提一点的是， MySQL查询优化器优先分析使用唯一二级索引的成本，再分析使用普通索引的成本，所以我们也先分析idx_key2的成本，然后再看使用idx_key1的成本
对于索引idx_key2的搜索条件是key2 > 10 AND key2 < 1000，这里还有回表的成本，计算这种查询的成本依赖两个方面的数据：范围区间数量
不论某个范围区间的二级索引到底占用了多少页面，查询优化器都认为读取索引的一个范围区间的I/O成本和读取一个页面是相同的。 本例中使用idx_key2的范围区间只有一个：(10, 1000)，所以相当于访问这个范围区间的二级索引付出的I/O成本就是：1 x 1.0 = 1.0
需要回表的记录数
优化器需要计算二级索引的某个范围区间到底包含多少条记录，对于本例来说就是要计算idx_key2在(10, 1000)这个范围区间中包含多少二级索引记录，计算过程是这样的：
先根据key2 > 10这个条件访问一下idx_key2对应的B+树索引，找到满足key2 > 10这个条件的第一条记录，这条记录称之为区间最左记录。 在B+数树中定位一条记录的过程是非常快的，是常数级别的，所以这个过程的性能消耗是可以忽略不计的
然后再根据key2 < 1000这个条件继续从idx_key2对应的B+树索引中找出第一条满足这个条件的记录，这条记录称之为区间最右记录，这个过程的性能消耗也可以忽略不计的。
如果区间最左记录和区间最右记录相隔不太远（在MySQL 5.7.21这个版本里，只要相隔不大于10个页面即可），那就可以精确统计出满足key2 > 10 AND key2 < 1000条件的二级索引记录条数。 否则只沿着区间最左记录向右读10个页面，计算平均每个页面中包含多少记录，然后用这个平均值乘以区间最左记录和区间最右记录之间的页面数量就可以了。
那么怎么估计区间最左记录和区间最右记录之间有多少个页面呢？我们有一章内容专门分析了B+Tree，假设区间最左记录在页a，区间最右记录在页h，那么就看他们对应的父节点，父节点存储着目录项记录， 每一条目录项记录都对应一个数据页，所以计算页a和页h之间有多少页面就相当于计算它们父节点中对应的目录项记录之间隔着几条记录。在一个页面中统计两条记录之间有几条记录的成本就很小了
根据上述算法测得idx_key2在区间(10, 1000)之间大约有95条记录。读取这95条二级索引记录需要付出的CPU成本就是：95 x 0.2 + 0.01 = 19.01
其中95是需要读取的二级索引记录条数，0.2是读取一条记录成本常数，0.01是微调。
在通过二级索引获取到记录之后，还需要计算回表成本：
根据这些记录里的主键值到聚簇索引中做回表操作
MySQL认为每次回表操作都相当于访问一个页面，也就是说二级索引范围区间有多少记录，就需要进行多少次回表操作，也就是需要进行多少次页面I/O。 95条二级索引记录回表操作带来的I/O成本就是：95 x 1.0 = 95.0
其中95是预计的二级索引记录数，1.0是一个页面的I/O成本常数。
回表操作后得到的完整用户记录，然后再检测其他搜索条件是否成立
回表操作的本质就是通过二级索引记录的主键值到聚簇索引中找到完整的用户记录，然后再检测除key2 > 10 AND key2 < 1000这个搜索条件以外的搜索条件是否成立。 因为我们通过范围区间获取到二级索引记录共95条，也就对应着聚簇索引中95条完整的用户记录，读取并检测这些完整的用户记录是否符合其余的搜索条件的CPU成本如下：95 x 0.2 = 19.0
其中95是待检测记录的条数，0.2是检测一条记录是否符合给定的搜索条件的成本常数。
所以本例中使用idx_key2执行查询的成本就如下所示：
I/O成本：1.0 + 95 x 1.0 = 96.0 (范围区间的数量 + 预估的二级索引记录条数)
CPU成本：95 x 0.2 + 0.01 + 95 x 0.2 = 38.01 （读取二级索引记录的成本 + 读取并检测回表后聚簇索引记录的成本）
综上所述，使用idx_key2执行查询的总成本就是：96.0 + 38.01 = 134.01
使用idx_key1执行查询的成本分析idx_key1对应的搜索条件是：key1 IN (‘a’, ‘b’, ‘c’)，也就是说相当于3个单点区间：
与使用idx_key2的情况类似，我们也需要计算使用idx_key1时需要访问的范围区间数量以及需要回表的记录数：
范围区间数量
使用idx_key1执行查询时很显然有3个单点区间，所以访问这3个范围区间的二级索引付出的I/O成本就是：3 x 1.0 = 3.0
需要回表的记录数
由于使用idx_key1时有3个单点区间，所以每个单点区间都需要查找一遍对应的二级索引记录数：
查找单点区间[‘a’, ‘a’]对应的二级索引记录数
计算单点区间对应的二级索引记录数和计算连续范围区间对应的二级索引记录数采用的都是统一的算法，都是先计算区间最左记录和区间最右记录，然后再计算它们之间的记录数，最后计算得到单点区间[‘a’, ‘a’]对应的二级索引记录数是：35
查找单点区间[‘b’, ‘b’]对应的二级索引记录数
与上同理，计算得到本单点区间对应的记录数是：44
查找单点区间[‘c’, ‘c’]对应的二级索引记录数
与上同理，计算得到本单点区间对应的记录数是：39
所以，这三个单点区间总共需要回表的记录数就是：35 + 44 + 39 = 118
读取这些二级索引记录的CPU成本就是：118 x 0.2 + 0.01 = 23.61
得到总共需要回表的记录数之后，就要考虑：
根据这些记录里的主键值到聚簇索引中做回表操作
所需的I/O成本就是：118 x 1.0 = 118.0
回表操作后得到的完整用户记录，然后再比较其他搜索条件是否成立
此步骤对应的CPU成本就是：118 x 0.2 = 23.6
所以使用idx_key1执行查询的成本就如下所示：
I/O成本：3.0 + 118 x 1.0 = 121.0 (范围区间的数量 + 预估的二级索引记录条数)
CPU成本：118 x 0.2 + 0.01 + 118 x 0.2 = 47.21 （读取二级索引记录的成本 + 读取并检测回表后聚簇索引记录的成本）
综上所述，使用idx_key1执行查询的总成本就是：121.0 + 47.21 = 168.21
执行本例中的查询的各种可执行方案以及它们对应的成本列出来：
很显然，使用idx_key2的成本最低，所以当然选择idx_key2来执行查询
有使用索引执行查询时会有许多单点区间，比如使用IN语句就很容易产生非常多的单点区间，下边这个查询：
SELECT * FROM single_table WHERE key1 IN (‘a’, ‘b’, ‘c’, … , ‘z’);
很显然，这个查询可能使用到的索引就是idx_key1，由于这个索引并不是唯一二级索引，所以并不能确定一个单点区间对应的二级索引记录的条数有多少， 计算方式上边提到的，就是先获取索引对应的B+树的区间最左记录和区间最右记录，然后再计算这两条记录之间有多少记录（记录条数少的时候可以做到精确计算，多的时候只能估算）。 MySQL把这种通过直接访问索引对应的B+树来计算某个范围区间对应的索引记录条数的方式称之为index dive。
单点区间不宜系统变量默认值，可以使用下面语句查询系统默认值：
SHOW VARIABLES LIKE '%dive%';
MySQL 5.6中这个系统变量的默认值是10，也就是说如果我们的IN语句中的参数个数小于10个的话，将使用index dive的方式计算各个单点区间对应的记录条数， 如果大于或等于10个的话，可就不能使用index dive了，要使用索引统计数据来进行估算
首先像会为每个表维护一份统计数据一样，MySQL也会为表中的每一个索引维护一份统计数据， 查看某个表中索引的统计数据可以使用如下查询：
SHOW INDEX FROM 表名
查询表single_table索引信息：
+--------------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| single_table | 0 | PRIMARY | 1 | id | A | 9693 | NULL | NULL | | BTREE | | |
| single_table | 0 | idx_key2 | 1 | key2 | A | 9693 | NULL | NULL | YES | BTREE | | |
| single_table | 1 | idx_key1 | 1 | key1 | A | 968 | NULL | NULL | YES | BTREE | | |
| single_table | 1 | idx_key3 | 1 | key3 | A | 799 | NULL | NULL | YES | BTREE | | |
| single_table | 1 | idx_key_part | 1 | key_part1 | A | 9673 | NULL | NULL | YES | BTREE | | |
| single_table | 1 | idx_key_part | 2 | key_part2 | A | 9999 | NULL | NULL | YES | BTREE | | |
| single_table | 1 | idx_key_part | 3 | key_part3 | A | 10000 | NULL | NULL | YES | BTREE | | |
+--------------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| 属性名 | 描述 |
|---|---|
| Table | 索引所属表的名称 |
| Non_unique | 索引列的值是否是唯一的，聚簇索引和唯一二级索引的该列值为0，普通二级索引该列值为1 |
| Key_name | 索引的名称 |
| Seq_in_index | 索引列在索引中的位置，从1开始计数。比如对于联合索引idx_key_part，来说，key_part1、key_part2和key_part3对应的位置分别是1、2、3 |
| Column_name | 索引列的名称 |
| Collation | 索引列中的值是按照何种排序方式存放的，值为A时代表升序存放，为NULL时代表降序存放 |
| Cardinality | 索引列中不重复值的数量。后边我们会重点看这个属性的 |
| Sub_part | 对于存储字符串或者字节串的列来说，有时候我们只想对这些串的前n个字符或字节建立索引，这个属性表示的就是那个n值。如果对完整的列建立索引的话，该属性的值就是NULL |
| Packed | 索引列如何被压缩，NULL值表示未被压缩。这个属性我们暂时不了解，可以先忽略掉 |
| Null | 该索引列是否允许存储NULL值 |
| Index_type | 使用索引的类型，我们最常见的就是BTREE，其实也就是B+树索引 |
| Comment | 索引列注释信息 |
| Index_comment | 索引注释信息 |
Cardinality属性，Cardinality直译过来就是基数的意思，表示索引列中不重复值的个数。 对于一个10000行记录的表来说，某个索引列的Cardinality属性是10000，那意味着该列中没有重复的值，如果Cardinality属性是1的话，就意味着该列的值全部是重复的。不 对于InnoDB存储引擎来说，使用SHOW INDEX语句展示出来的某个索引列的Cardinality属性是一个估计值，并不是精确的
索引统计数据指的是这两个值：
表中记录总数
使用SHOW INDEX语句展示出的Cardinality属性
结合上一个Rows统计数据，可以针对索引列，计算出平均一个值重复多少次，一个值的重复次数 ≈ Rows ÷ Cardinality
以本表的idx_key1索引为例，它的Rows值是9693，它对应索引列key1的Cardinality值是968，所以我们可以计算key1列平均单个值的重复次数就是：9693 ÷ 968 ≈ 10条
此时再看上边那条查询语句：
SELECT * FROM single_table WHERE key1 IN ('a', 'b', 'c', ... , 'z');
假设IN语句中有20000个参数的话，就直接使用统计数据来估算这些参数需要单点区间对应的记录条数了，每个参数大约对应10条记录，所以总共需要回表的记录数就是20000 x 10 = 200000 ，使用统计数据来计算单点区间对应的索引记录条数可比index dive的方式简单多了，但是它的致命弱点就是不精确！使用统计数据算出来的查询成本与实际所需的成本可能相差非常大
在MySQL 5.7.3之后的版本中，eq_range_index_dive_limit的默认值为200，所以如果大家采用的是5.7.3以及之前的版本的话， 很容易采用索引统计数据而不是index dive的方式来计算查询成本。
这里有一个没有用到索引的情况就是当你的查询中使用到了IN查询，但是却实际没有用到索引，就应该考虑一下是不是由于 eq_range_index_dive_limit 值太小或者传入的参数太多导致的
连接查询至少要有两张表，所以创建一个与上表相同的single_talbe2表，记为s2表。在介绍了解的文章中提到了连接的本质，那么连接的查询成本就是：
MySQL中对驱动表进行查询后得到的记录条数称之为驱动表的扇出fanout。那么fanout值越小也就说明连接查询总成本越低。计算驱动表的fanout值有多种情况：
这个过程称为条件过滤condition filtering
连接查询的成本计算公式是这样的：连接查询总成本 = 单次访问驱动表的成本 + 驱动表扇出数 x 单次访问被驱动表的成本
对于左外连接和右外连接查询来说，它们的驱动表是固定的，所以想要得到最优的查询方案只需要分别为驱动表和被驱动表选择成本最低的访问方法，关于访问方法可以参考这篇文章， 而对于内连接来说，驱动表和被驱动表的位置是可以互换的，所以需要考虑两个方面的问题：
以下面的内连接查询为例：
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;
连接的顺序有两种：
查询优化器需计算这两种连接顺序最优查询成本，然后选取那个成本更低的连接顺序以及该连接顺序下各个表的最优访问方法作为最终的查询计划
第一种连接顺序
驱动表的成本最低的执行方案
涉及s1表单表的搜索条件只有s1.key2 > 10 AND s1.key2 < 1000，所以这个查询可能使用到idx_key2索引，从全表扫描和使用idx_key2这两个方案中选出成本最低的那个， 具体选取过程上面已经提到
被驱动表的成本最低的执行方案
被驱动表s2的搜索条件就是：s2.common_field = 常数、s2.key2 > 1000 AND s2.key2 < 2000； s2.common_field = 常数 这个条件因为对驱动表s1结果集中的每一条记录，都需要进行一次被驱动表s2的访问，此时那些涉及两表的条件现在相当于只涉及被驱动表s2了， 第一个条件由于common_field没有用到索引，此时访问s2表时可用的方案也是全表扫描和使用idx_key2两种，假设使用idx_key2的成本更小
所以此时使用s1作为驱动表时的总成本就是：使用idx_key2访问s1的成本 + s1的扇出 × 使用idx_key2访问s2的成本
第二种连接顺序
驱动表的成本最低的执行方案
s2表单表的搜索条件只有：s2.key2 > 1000 AND s2.key2 < 2000， 所以这个查询可能使用到idx_key2索引，从全表扫描和使用idx_key2这两个方案中选出成本最低的那个，假设使用idx_key2执行查询的成本更低些
被驱动表的成本最低的执行方案
被驱动表s1的搜索条件就是：s1.key1 = 常数、s1.key2 > 10 AND s1.key2 < 2000，使用idx_key1可以进行ref方式的访问， 使用idx_key2可以使用range方式的访问。优化器需要从全表扫描、使用idx_key1、使用idx_key2这几个方案里选出一个成本最低的方案。 idx_key2的范围区间是确定的，怎么计算使用idx_key2的成本上边已经提到了，在没有真正执行查询前， s1.key1 = 常数中的常数值我们是不知道的，那么衡量使用idx_key1执行查询的成本就可以使用上面提到的索引统计数据（就是索引列平均一个值重复多少次）。 一般情况下，ref的访问方式要比range成本更低，这里假设使用idx_key1进行对s1的访问
所以此时使用s2作为驱动表时的总成本就是：使用idx_key2访问s2的成本 + s2的扇出 × 使用idx_key1访问s1的成本
不管是哪种连接顺序fanout值很大程度上会影响成本，所以就有了优化方向：
对被驱动表的访问成本尽量低
尽量在被驱动表的连接列上建立索引，这样就可以使用ref访问方法来降低访问被驱动表的成本了。如果可以， 被驱动表的连接列最好是该表的主键或者唯一二级索引列，这样就可以把访问被驱动表的成本降到更低了
对于内连接如果2个表连接查询就有2种组合，如果3个表连接查询就有3X2X1=6种可能，如果4个表连接查询就有4X3X2X1=24中可能，如果n代表表的个数那么就有n!（n的阶乘）中可能， 针对这种情况MySQL也有自己处理：
提前结束某种顺序的成本评估
MySQL在计算各种连接顺序的成本之前，会维护一个全局的变量，这个变量表示当前最小的连接查询成本。 如果在分析某个连接顺序的成本时，该成本已经超过当前最小的连接查询成本，那不会对该连接顺序继续往下分析了。例如A、B、C三个表进行连接， 已经得到连接顺序ABC是当前的最小连接成本，在计算连接顺序BCA时，发现B和C的连接成本就已经大于10.0时，就不再继续往后分析BCA这个连接顺序的成本了
系统变量optimizer_search_depth
为了防止无穷无尽的分析各种连接顺序的成本，MySQL有个optimizer_search_depth系统变量，如果连接表的个数小于该值， 那么就继续穷举分析每一种连接顺序的成本，否则只对与optimizer_search_depth值相同数量的表进行穷举分析。该值越大，成本分析的越精确， 越容易得到好的执行计划，但是消耗的时间也就越长，否则得到不是很好的执行计划，但可以省掉很多分析连接成本的时间。可以使用如下命令查看这个系统变量的值：
SHOW VARIABLES LIKE '%optimizer_search_depth%';
根据某些规则就不考虑某些连接顺序
即使是有上边两条规则的限制，但是分析多个表不同连接顺序成本花费的时间还是会很长，同样MySQL制定了一个启发式规则（就是根据以往经验指定的一些规则）， 凡是不满足这些规则的连接顺序就不分析，这样可以极大的减少需要分析的连接顺序的数量， 但是也可能造成错失最优的执行计划。提供了一个系统变量optimizer_prune_level来控制到底是不是用这些启发式规则，可以使用如下命令查看这个系统变量的值：
SHOW VARIABLES LIKE '%optimizer_prune_level%';