在mysql官方手册上，关于index merge的介绍非常非常少。甚至还有不少误导的地方，这次把5.1版本关于此类优化处理的代码细看了一遍，以案例的方式介绍了各种实用index merge访问类型的sql。后续的还会继续介绍index merge实现的主要数据结构，以及成本评估。
在mysql官方手册上，关于index merge的介绍非常非常少。甚至还有不少误导的地方，这次把5.1版本关于此类优化处理的代码细看了一遍，以案例的方式介绍了各种实用index merge访问类型的sql。后续的还会继续介绍index merge实现的主要数据结构，以及成本评估。
目录
1. 什么是index merge1.1 index merge的限制：range优先2. 关于index merge的一些案例2.1 k1_p1 = 2 or k2_p1 = 42.2 (k1_p1=2 and k1_p2=7) or k2_p1=4\g2.3 (k1_p1=2 or k1_p1=7) or k2_p1=4\g2.4 (k1_p1=2 or k1_p2=7) or k2_p1=4\g2.5 k1_p1=1 or (k1_p1=2 and k1_p2=4 and k2_p1=3)2.6 嵌套的案例12.7 嵌套的案例23. 更多关于range优先原则可以使用range的情况4. 其他4.1 type in mysql explain4.2 示例中的表结构和数据1. 什么是index mergemysql优化器如果发现可以使用多个索引查找后的交集/并集定位数据，那么mysql优化器就会尝试index merge这类访问方式。index merge主要分为两大类，多个索引交集访问(intersections)，多个索引并集访问，当然这两类还可以组合出更为复杂的方式，例如多个交集后做并集。
1.1 index merge的限制：range优先mysql在5.6.7之前，使用index merge有一个重要的前提条件：没有range可以使用。这个限制降低了mysql index merge可以使用的场景。理想状态是同时评估成本后然后做出选择。因为这个限制，就有了下面这个已知的bad case(参考)：
select * from t1 where (goodkey1 优化器可以选择使用goodkey1和goodkey2做index merge，也可以使用badkey做range。因为上面的原则，无论goodkey1和goodkey2的选择度如何，mysql都只会考虑range，而不会使用index merge的访问方式。这是一个悲剧...（5.6.7版本针对此有修复)
2. 关于index merge的一些案例关于什么是交集/并集在手册中有详细介绍，这里不赘述。这里通过几个案例来看看，哪些情况使用交集，哪些情况使用并集，哪些情况使用更复杂的组合。
示例中使用的表结构和数据参考本文4.2节。
2.1 k1_p1 = 2 or k2_p1 = 4这是最典型，也是最简单的场景了：
select * from tmp_index_merge where key1_part1 = 2 or key2_part1 = 4
explain select * from tmp_index_merge where key1_part1 = 2 or key2_part1 = 4\g ...... table: tmp_index_merge type: index_merge key: ind1,ind2 key_len: 4,4 extra: using sort_union(ind1,ind2); using where
2.2 (k1_p1=2 and k1_p2=7) or k2_p1=4\g这个案例稍微复杂一丁点，第一个索引使用了两个字段：
explain select * from tmp_index_mergewhere (key1_part1 = 2 and key1_part2 = 7) or key2_part1 = 4\g ...... table: tmp_index_merge type: index_merge key: ind1,ind2 key_len: 8,4 extra: using sort_union(ind1,ind2); using where
2.3 (k1_p1=2 or k1_p1=7) or k2_p1=4\g这个案例也能够使用index merge。内部的实现比它表面上看起来要复杂，这里简单解释一下：mysql在递归处理这个where条件时，先处理前一部分(key1_part1 = 2 or key1_part1 = 7)。对于同一个索引的同一个字段进行or操作，mysql会将其合并成一颗sel_arg树(具体参考)，两个条件通过sel_arg的next/prev指针连接。mysql的range访问方式可以通过遍历这棵树(也可以参考前面这篇文章)。接着优化器再处理or的另一个分支(key2_part1 = 4)发现可以使用第二个索引，于是将index merge加入可能的执行计划列表(后续评估成本，再决定是否实用该访问方式)。
explain select * from tmp_index_mergewhere (key1_part1 = 2 or key1_part1 = 7) or key2_part1 = 4\g ...... table: tmp_index_merge type: index_merge key: ind1,ind2 key_len: 4,4 extra: using sort_union(ind1,ind2); using where
2.4 (k1_p1=2 or k1_p2=7) or k2_p1=4\g这种情况是无法直接使用任何索引的。不解释。
explain select * from tmp_index_mergewhere (key1_part1 = 2 or key1_part2 = 7) or key2_part1 = 4\g ...... table: tmp_index_merge type: allpossible_keys: ind1,ind2 key: null extra: using where
2.5 k1_p1=1 or (k1_p1=2 and k1_p2=4 and k2_p1=3)对于这样的条件，mysql会发现可以使用range访问方式。而根据前面的range优先原则，mysql不再考虑index merge(这里k1_p1=1和k2_p1=3是可以通过index merge访问方式实现的)。mysql在考虑使用key1访问的时候，看到的条件是：k1_p1=1 or (k1_p1=2 and k1_p2=4)。这里or两边的条件可以构造成一颗独立的sel_arg。(本文后面小结“更多关于range优先原则”有更多详细介绍)
所以，mysql会直接使用range，而不再考虑index merge。(怎样的条件无法够着成一颗sel_arg树，参考，对于两颗sel_arg通过or合并的时候，还有一些更复杂的事情，这里暂时不做介绍)
explain select * from tmp_sel_treewhere key1_part1=1 or (key1_part1=2 and key1_part2=4 and key2_part1=3)\g table: tmp_sel_tree type: range key: ind1 key_len: 8 extra: using where
如果前面这几个案例看明白了，那可以继续了，下面会有一些更复杂的案例：
2.6 嵌套的案例1这个案例看起来很复杂，但其本质跟最前面提到的已知的bad case相同，是一个可以使用index merge，但是被range优先掉的案例。
select * from tmp_sel_tree where ( key1_part1 = 1 or (key1_part2 = 2 and key2_part1 = 3) ) and ( key3_part1 = 5 )
2.7 嵌套的案例2这个案例跟上面稍有不同，是一个三个索引的index merge，这里mysql将考虑使用index merge。但是一般来说，这类index merge成本本身较大，容易超过全表的成本：
select * from tmp_sel_tree where ( key1_part1 = 1 or (key1_part2 = 2 and key2_part1 = 3) ) or ( key3_part1 = 5 )
如果成本评估后，发现index merge成本小于全表，则会使用：
table: tmp_sel_tree type: index_merge key: ind1,ind2,ind3 extra: using sort_union(ind1,ind2,ind3); using where
3. 更多关于range优先原则可以使用range的情况在5.6.7之前的mysql版本，只要可以使用range访问方式，那就不会再使用index merge。因为可以使用range访问的where条件是非常多的，除了我们常见的(k1_p1=const and k2_p2>const)，如果参考range优化相关的数据结构，还会看到更多的where条件可以使用range。
这里拿出其中一个较为复杂的可以使用range访问的where条件，做一个简单分析。
where ( key1_part1 = 3 and key1_part2 > 5 and key2_part1 = 7 ) or ( key1_part1 > 2 )
对于索引key2来说，这个条件可以简化为如下，可以使用index merge的访问方式：
(true and true and key2_part1 = 7) or ( key1_part1 对于索引key1来说，条件简化为：
(key1_part1 = 3 and key1_part2 > 5 and true) or (key1_part1 > 2)
对于索引key1，这是一个可以使用range访问方式的条件。根据前文range优化相关的数据结构可以构造成一颗sel_arg结构，如下：
$ $sel_arg[2,∞) $ $ |^ $ $ next|| $ $ ||prev $ $ v| $ $sel_arg[3,3] ==$====> sel_arg[5,∞] $ $ $
range访问会依次sel_arg，遍历访问。因为有range访问方式，所以这类条件不会再考虑index merge。
但如果where是如下样子（or后面条件是key1_part2而不是key1_part1）：
where ( key1_part1 = 3 and key1_part2 > 5 and key2_part1 = 7 ) or ( key1_part2 > 2 )
or后面的key1_part2是无法与前面的key1条件合并成一颗sel_arg树，所以也就无法使用range访问。因为or后面条件无法独立使用索引访问，所以也同样无法做index merge访问。
4. 其他4.1 type in mysql explain在mysql手册中把explain中type列称为：explain join types。这给很多人产生了误解，这里的type实际是指在整个join中这个单表的访问方式。例如：
id: 1 select_type: simple table: tmp_sel_tree type: index_mergepossible_keys: ind1,ind2,ind3 key: ind1,ind2,ind3 key_len: 4,4,4
常见的单表访问方式有：const/ref/range/index/all
mysql的优化器主要有两个自由度，一个是确定每个单表的访问方式。另一个就是访问顺序。博客中常说的使用range优化 index merge优化也是指mysql单表访问方式选择了range或者index merge。
4.2 示例中的表结构和数据create table `tmp_index_merge` ( `id` int(11) not null, `key1_part1` int(11) not null, `key1_part2` int(11) not null, `key2_part1` int(11) not null, `key2_part2` int(11) not null, `key2_part3` int(11) not null, `key3_part1` int(11) not null default '4', key `ind1` (`key1_part1`,`key1_part2`), key `ind2` (`key2_part1`,`key2_part2`,`key2_part3`), key `ind3` (`key3_part1`)) engine=innodb default charset=gbk1 row in set (0.01 sec)root@test 11:33:22>select * from tmp_index_merge;+----+------------+------------+------------+------------+------------+------------+| id | key1_part1 | key1_part2 | key2_part1 | key2_part2 | key2_part3 | key3_part1 |+----+------------+------------+------------+------------+------------+------------+| 6 | 6 | 1 | 9 | 2 | 1 | 8 || 8 | 9 | 9 | 1 | 6 | 6 | 6 || 4 | 1 | 3 | 4 | 9 | 3 | 6 || 10 | 9 | 7 | 5 | 7 | 1 | 2 || 1 | 4 | 7 | 2 | 1 | 8 | 3 || 6 | 6 | 3 | 9 | 3 | 9 | 7 || 8 | 10 | 6 | 2 | 1 | 1 | 7 || 0 | 9 | 4 | 4 | 8 | 7 | 6 || 2 | 9 | 1 | 5 | 4 | 5 | 7 || 2 | 7 | 10 | 6 | 1 | 8 | 6 || 7 | 10 | 8 | 2 | 3 | 1 | 9 || 7 | 3 | 3 | 7 | 7 | 2 | 10 || 6 | 6 | 1 | 9 | 2 | 1 | 8 || 8 | 9 | 9 | 1 | 6 | 6 | 6 || 4 | 1 | 3 | 4 | 9 | 3 | 6 || 10 | 9 | 7 | 5 | 7 | 1 | 2 || 1 | 4 | 7 | 2 | 1 | 8 | 3 || 6 | 6 | 3 | 9 | 3 | 9 | 7 || 8 | 10 | 6 | 2 | 1 | 1 | 7 || 0 | 9 | 4 | 4 | 8 | 7 | 6 || 2 | 9 | 1 | 5 | 4 | 5 | 7 || 2 | 7 | 10 | 6 | 1 | 8 | 6 || 7 | 10 | 8 | 2 | 3 | 1 | 9 || 7 | 3 | 3 | 7 | 7 | 2 | 10 |+----+------------+------------+------------+------------+------------+------------+