前言
这内容依旧是来自于《MySQL是怎样运行的》
单表的访问访问方法
开始之前
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=utf8;
我们为这个 single_table 表建立了1个聚簇索引和4个二级索引，分别是：
为 id 列建立的聚簇索引。
为 key1 列建立的 idx_key1 二级索引。
为 key2 列建立的 idx_key2 二级索引，而且该索引是唯一二级索引。
为 key3 列建立的 idx_key3 二级索引。
为 key_part1 、 key_part2 、 key_part3 列建立的 idx_key_part 二级索引，这也是一个联合索引。
访问方法的概念
MySQL把查询的执行方式大致分为下边两种：
1、使用全表扫描进行查询
这种执行方式很好理解，就是把表的每一行记录都扫一遍嘛，把符合搜索条件的记录加入到结果集就完了。不管是啥查询都可以使用这种方式执行，当然，这种也是最笨的执行方式。
2、使用索引进行查询
因为直接使用全表扫描的方式执行查询要遍历好多记录，所以代价可能太大了。如果查询语句中的搜索条件可以使用到某个索引，那直接使用索引来执行查询可能会加快查询执行的时间。使用索引来执行查询的方式五花八门，又可以细分为许多种类：
针对主键或唯一二级索引的等值查询
针对普通二级索引的等值查询
针对索引列的范围查询
直接扫描整个索引
MySQL 执行查询语句的方式称之为 访问方法 或者 访问类型 。同一个查询语句可能可以使用多种不同的访问方法来执行，虽然最后的查询结果都是一样的，但是执行的时间可能差很远。
1、const
MySQL的设计者认为通过主键或者唯一二级索引列与常数的等值比较来定位一条记录是像坐火箭一样快的，所以他们把这种通过主键或者唯一二级索引列来定位一条记录的访问方法定义为： const ，意思是常数级别的，代价是可以忽略不计的。不过这种 const 访问方法只能在主键列或者唯一二级索引列和一个常数进行等值比较时才有效，如果主键或者唯一二级索引是由多个列构成的话，索引中的每一个列都需要与常数进行等值比较，这个const 访问方法才有效（这是因为只有该索引中全部列都采用等值比较才可以定位唯一的一条记录）。
eg：
SELECT * FROM single_table WHERE id = 1438;
SELECT * FROM single_table WHERE key2 = 3841;
对于唯一二级索引来说，查询该列为 NULL 值的情况比较特殊，比如这样：
SELECT * FROM single_table WHERE key2 IS NULL;
因为唯一二级索引列并不限制 NULL 值的数量，所以上述语句可能访问到多条记录，也就是说 上边这个语句不可
以使用 const 访问方法来执行
2、ref
由于普通二级索引并不限制索引列值的唯一性，所以可能找到多条对应的记录，也就是说使用二级索引来执行查询的代价取决于等值匹配到的二级索引记录条数。如果匹配的记录较少，则回表的代价还是比较低的，所以 MySQL 可能选择使用索引而不是全表扫描的方式来执行查询。MySQL 就把这种搜索条件为二级索引列与常数等值比较，采用二级索引来执行查询的访问方法称为： ref 。
eg：
SELECT * FROM single_table WHERE key1 = 'abc';
注意：
1、二级索引列值为 NULL 的情况
不论是普通的二级索引，还是唯一二级索引，它们的索引列对包含 NULL 值的数量并不限制，所以我们采用
key IS NULL 这种形式的搜索条件最多只能使用 ref 的访问方法，而不是 const 的访问方法。
2、对于某个包含多个索引列的二级索引来说，只要是最左边的连续索引列是与常数的等值比较就可能采用 ref
的访问方法。
这样的就不能采用ref。
SELECT * FROM single_table WHERE key_part1 = 'god like' AND key_part2 > 'legendary';
3、ref_or_null
有时候我们不仅想找出某个二级索引列的值等于某个常数的记录，还想把该列的值为 NULL 的记录也找出来，当使用二级索引而不是全表扫描的方式执行该查询时，这种类型的查询使用的访问方法就称为ref_or_null。
eg：
SELECT * FROM single_demo WHERE key1 = 'abc' OR key1 IS NULL;
4、range
利用索引进行范围匹配的访问方法称之为： range 。此处所说的使用索引进行范围匹配中的索引可以是聚簇索引，也可以是二级索引。
SELECT * FROM single_table WHERE key2 IN (1438, 6328) OR (key2 >= 38 AND key2 <= 79);
key2 的值是 1438
key2 的值是 6328
key2 的值在 38 和 79 之间。
对于 B+ 树索引来说，只要索引列和常数使用 = 、 <=> 、 IN 、 NOT IN 、 IS NULL 、 IS NOT NULL 、> 、 < 、 >= 、 <= 、 BETWEEN 、 != （不等于也可以写成 <> ）或者 LIKE 操作符连接起来，就可以产生一个所谓的 区间 。
5/index
由于二级索引记录比聚簇索记录小的多（聚簇索引记录要存储所有用户定义的列以及所谓的隐藏列，而二级索记
录只需要存放索引列和主键），而且这个过程也不用进行回表操作，所以直接遍历二级索引比直接遍历聚簇索引
的成本要小很多， MySQL 把这种采用遍历二级索引记录的执行方式称之为： index 。
简单点说就是：要查找的列刚好就是某一个索引里包含的列，搜索条件也是索引的列，那么这时候直接查二级索引就行，不需要回表操作。
eg:
SELECT key_part1, key_part2, key_part3 FROM single_table WHERE key_part2 = 'abc';
直接通过遍历 idx_key_part 索引的叶子节点的记录来比较 key_part2 = ‘abc’ 这个条件是否成立，把匹配成功的二级索引记录的 key_part1 , key_part2 , key_part3 列的值直接加到结果集中就行了。
索引合并
MySQL 在一般情况下执行一个查询时最多只会用到单个二级索引，但不是还有特殊情况么，在这些特殊情况下也可能在一个查询中使用到多个二级索引，MySQL把这种使用到多个索引来完成一次查询的执行方法称之为： index merge ，具体的索引合并算法有下边三种。
1、Intersection合并
Intersection 翻译过来的意思是 交集 。这里是说某个查询可以使用多个二级索引，将从多个二级索引中查询到的结果取交集。
eg：
SELECT * FROM single_table WHERE key1 = 'a' AND key3 = 'b';
执行步骤：
从 idx_key1 二级索引对应的 B+ 树中取出 key1 = 'a' 的相关记录。
从 idx_key3 二级索引对应的 B+ 树中取出 key3 = 'b' 的相关记录。
二级索引的记录都是由 索引列 + 主键 构成的，所以我们可以计算出这两个结果集中 id 值的交集。
按照上一步生成的 id 值列表进行回表操作，也就是从聚簇索引中把指定 id 值的完整用户记录取出来，返回
给用户。
为啥不直接使用 idx_key1 或者 idx_key3 只根据某个搜索条件去读取一个二级索引，然后回表后再过滤另外一个搜索条件呢？
只读取一个二级索引的成本：
1、按照某个搜索条件读取一个二级索引
2、根据从该二级索引得到的主键值进行回表操作，然后再过滤其他的搜索条件
读取多个二级索引之后取交集成本：
1、按照不同的搜索条件分别读取不同的二级索引
2、将从多个二级索引得到的主键值取交集，然后进行回表操作
虽然读取多个二级索引比读取一个二级索引消耗性能，但是读取二级索引的操作是 顺序I/O ，而回表操作是 随机I/O ，
所以如果只读取一个二级索引时需要回表的记录数特别多，而读取多个二级索引之后取交集的记录数非常少，
当节省的因为 回表 而造成的性能损耗比访问多个二级索引带来的性能损耗更高时，
读取多个二级索引后取交集比只读取一个二级索引的成本更低。
MySQL 在某些特定的情况下才可能会使用到 Intersection 索引合并：
情况一：二级索引列是等值匹配的情况，对于联合索引来说，在联合索引中的每个列都必须等值匹配，不能
出现只出现匹配部分列的情况。
eg:
SELECT * FROM single_table WHERE key1 > 'a' AND key_part1 = 'a' AND key_part2 = 'b' AND key_part3 = 'c';
SELECT * FROM single_table WHERE key1 = 'a' AND key_part1 = 'a';
第一个查询是因为对 key1 进行了范围匹配，第二个查询是因为联合索引 idx_key_part 中的 key_part2 列
并没有出现在搜索条件中，所以这两个查询不能进行 Intersection 索引合并。
情况二：主键列可以是范围匹配
eg:
SELECT * FROM single_table WHERE id > 100 AND key1 = 'a';
对于 InnoDB 的二级索引来说，记录先是按照索引列进行排序，如果该二级索引是一个联合索引，
那么会按照联合索引中的各个列依次排序。而二级索引的用户记录是由 索引列 + 主键 构成的，
二级索引列的值相同的记录可能会有好多条，这些索引列的值相同的记录又是按照主键 的值进行排序的。
所以重点来了，之所以在二级索引列都是等值匹配的情况下才可能使用 Intersection 索引合并，
是因为只有在这种情况下根据二级索引查询出的结果集是按照主键值排序的。
Intersection 索引合并会把从多个二级索引中查询出的主键值求交集，如果从各个二级索引中查询的到的结果集本身就是已经按照主键排好序的，那么求交集的过程就很快。
假设某个查询使用Intersection 索引合并的方式从 idx_key1 和 idx_key2 这两个二级索引中获取到的主键值分别是：
从 idx_key1 中获取到已经排好序的主键值：1、3、5
从 idx_key2 中获取到已经排好序的主键值：2、3、4
那么求交集的过程就是这样：
逐个取出这两个结果集中最小的主键值，如果两个值相等，则加入最后的交集结果中，否则丢弃当前较小的主键值，再取该丢弃的主键值所在结果集的后一个主键值来比较，直到某个结果集中的主键值用完了
先取出这两个结果集中较小的主键值做比较，因为 1 < 2 ，所以把 idx_key1 的结果集的主键值 1 丢弃，取
出后边的 3 来比较。
因为 3 > 2 ，所以把 idx_key2 的结果集的主键值 2 丢弃，取出后边的 3 来比较。
因为 3 = 3 ，所以把 3 加入到最后的交集结果中，继续两个结果集后边的主键值来比较。
后边的主键值也不相等，所以最后的交集结果中只包含主键值 3 。
2、Union合并
Intersection 是交集的意思，这适用于使用不同索引的搜索条件之间使用 AND 连接起来的情况； Union 是并集的意思，适用于使用不同索引的搜索条件之间使用 OR 连接起来的情况。
MySQL 在某些特定的情况下才可能会使用到 Union 索引合并：
情况一：二级索引列是等值匹配的情况，对于联合索引来说，在联合索引中的每个列都必须等值匹配，不能
出现只出现匹配部分列的情况。
情况二：主键列可以是范围匹配
情况一二和Intersection是一样的。
情况三：使用 Intersection 索引合并的搜索条件
搜索条件的某些部分使用 Intersection 索引合并的方式得到的主键集合和其他方式得到的主键集合取交集，
比方说这个查询：
SELECT * FROM single_table WHERE key_part1 = 'a' AND key_part2 = 'b' AND key_part3 ='c' OR (key1 = 'a' AND key3 = 'b');
优化器可能采用这样的方式来执行这个查询：
1、先按照搜索条件 key1 = 'a' AND key3 = 'b' 从索引 idx_key1 和 idx_key3 中使用 Intersection 索引
合并的方式得到一个主键集合。
2、再按照搜索条件 key_part1 = 'a' AND key_part2 = 'b' AND key_part3 = 'c' 从联合索引
idx_key_part 中得到另一个主键集合。
3、采用 Union 索引合并的方式把上述两个主键集合取并集，然后进行回表操作，将结果返回给用户。
另：优化器只有在单独根据搜索条件从某个二级索引中获取的记录数比较少，通过 Union 索引合并后进行访问的代价比全表扫描更小时才会使用 Union 索引合并。
3、Sort-Union合并
Union 索引合并的使用条件太苛刻，必须保证各个二级索引列在进行等值匹配的条件下才可能被用到。（Intersection不也一样？）
使用不到的eg：
SELECT * FROM single_table WHERE key1 < 'a' OR key3 > 'z'
这是因为根据 key1 < ‘a’ 从 idx_key1 索引中获取的二级索引记录的主键值不是排好序的（排序的必须是某一个索引列相同的情况下才进行下一列的排序），根据 key3 >‘z’ 从 idx_key3 索引中获取的二级索引记录的主键值也不是排好序的，但是 key1 < ‘a’ 和 key3 > ‘z’ 这两个条件又特别让我们动心，所以我们可以这样：
先根据 key1 < 'a' 条件从 idx_key1 二级索引总获取记录，并按照记录的主键值进行排序
再根据 key3 > 'z' 条件从 idx_key3 二级索引总获取记录，并按照记录的主键值进行排序
因为上述的两个二级索引主键值都是排好序的，剩下的操作和 Union 索引合并方式就一样了。
我们把上述这种先按照二级索引记录的主键值进行排序，之后按照 Union 索引合并方式执行的方式称之为 Sort-Union 索引合并，很显然，这种 Sort-Union 索引合并比单纯的 Union 索引合并多了一步对二级索引记录的主键值排序的过程。
为啥没有Sort-Intersection索引合并？
Sort-Union的适用场景是单独根据搜索条件从某个二级索引中获取的记录数比较少，这样即使对这些二
级索引记录按照主键值进行排序的成本也不会太高
而Intersection索引合并的适用场景是单独根据搜索条件从某个二级索引中获取的记录数太多，导致回
表开销太大，合并后可以明显降低回表开销，
但是如果加入Sort-Intersection后，就需要为大量的二级索引记录按照主键值进行排序，
这个成本可能比回表查询都高了，所以也就没有引入Sort-Intersection这个玩意儿。
联合索引替代Intersection索引合并
SELECT * FROM single_table WHERE key1 = 'a' AND key3 = 'b';
这个查询之所以可能使用 Intersection 索引合并的方式执行，还不是因为 idx_key1 和 idx_key3 是两个单独的 B+ 树索引，你要是把这两个列搞一个联合索引，那直接使用这个联合索引就把事情搞定了，何必用啥索引合并呢。
就是能建联合索引就建联合索引，如果业务需要建立单个索引，那就建单个索引，不然也就不用建两个单独索引搞出两个B+树了