1，system

应用场景：表中只有一条数据，且存储引擎可以准确的统计到这条数据。

system一般出现在MyISAM、memory类型的表查询中。

由于我们一般使用的存储引擎都是InnoDB，所以system这种类型很少会用到。

2，const

应用场景：通过主键或者唯一索引等值查询来定位一条数据。

比如：select * from test where id = 1;

我们知道，MySQL底层使用B+树来保存数据，其结构大体可类似下图，

那么我们在m字段上创建唯一索引约束，如果想找到m=103的记录，通过二分法只需简单两步就可以定位到m=103。

即100->102->103。

即使对于一张记录很多的真正的业务表，因为B+树矮胖的结构，定位一条唯一索引中的记录，速度也是非常快的。

可以粗略的认为，这种查询速度是常数级的。

所以，MySQL就把这种唯一索引或主键（主键也是一种唯一索引）等值匹配的查询定义为const（常数级）。

需要注意的是，由于唯一索引中允许存在多个null值，所以如果对唯一索引进行null值查询，是没法用const的。

3，eq_ref

应用场景：在进行多表连接查询时，被驱动表通过主键或唯一索引键进行等值查询。

比如：SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id;

4，ref

应用场景：普通二级索引等值查询。

比如：select * from t2 where key2 =4;

除了唯一索引，我们更多的会使用普通的二级索引。

由于通过二级索引，可能会查询到多个匹配值，相比const性能差那么一点。

MySQL就把这种类型的查询定义为了ref。

在上面我们说到，由于唯一索引可能存在多个null，所以用不了const。

那对于 select * from t2 where key2 is null 来说，不管是唯一索引还是普通索引，其最多用到ref这种类型。

5，ref_or_null

应用场景：命中索引时，查询条件除了等值查询，还包含null值查询。

比如：select * from t2 where key2 =4 or key2 is null;

其实看名字就很容易理解，MySQL会在B+树上，找到key2=1和key2 is null 这两种记录范围值，然后拿到主键id去回表查询相关信息。

6，index_merge

应用场景：查询条件可以命中多个索引的情况。

比如：select * from t3 where key1 =3 or key2 =4;

索引合并其实也很好理解，当查询条件可以命中多个索引时，MySQL会尝试在两个索引树查找匹配的条件，然后将结果其合并起来。

7，unique_subquery

应用场景：查询条件包含子查询，并且子查询的列可以进行主键等值匹配。

比如：SELECT * FROM t2 WHERE t2.key2 IN ( SELECT id FROM t3 WHERE t2.key2 = t3.key2 ) OR t2.key2 = 1;

通过查看MySQL优化的执行sql，可以看到MySQL将in子查询优化为了exist语句，并且在主键索引上进行了等值查询。

MySQL优化后的语句：/* select#1 */ select dbs.t2.id AS id,dbs.t2.key2 AS key2 from dbs.t2 where (<in_optimizer>(dbs.t2.key2,(<primary_index_lookup>((dbs.t2.key2) in t3 on PRIMARY where ((dbs.t2.key2 = dbs.t3.key2) and ((dbs.t2.key2) = dbs.t3.id))))) or (dbs.t2.key2 = 1))；