共计 2620 个字符，预计需要花费 7 分钟才能阅读完成。
| 导读 | 我们在使用 SQL 语句查询表数据时，提前用 explain 进行语句分析是一个非常好的习惯。通过 explain 输出 sql 的详细执行信息，就可以针对性的进行 sql 优化。今天我们来分析一下，在 explain 中 11 种不同 type 代表的含义以及其应用场景。 |
应用场景：表中只有一条数据，且存储引擎可以准确的统计到这条数据。
system 一般出现在 MyISAM、memory 类型的表查询中。
由于我们一般使用的存储引擎都是 InnoDB，所以 system 这种类型很少会用到。
应用场景：通过主键或者唯一索引等值查询来定位一条数据。
比如：select * from test where id = 1。
我们知道，MySQL 底层使用 B + 树来保存数据，其结构大体可类似下图，
那么我们在 m 字段上创建唯一索引约束，如果想找到 m =103 的记录，通过二分法只需简单两步就可以定位到 m =103。
即 100->102->103。
即使对于一张记录很多的真正的业务表，因为 B + 树矮胖的结构，定位一条唯一索引中的记录，速度也是非常快的。
可以粗略的认为，这种查询速度是常数级的。
所以，MySQL 就把这种唯一索引或主键（主键也是一种唯一索引）等值匹配的查询定义为 const（常数级）。
需要注意的是，由于唯一索引中允许存在多个 null 值，所以如果对唯一索引进行 null 值查询，是没法用 const 的。
应用场景：在进行多表连接查询时，被驱动表通过主键或唯一索引键进行等值查询。
比如：SELECT * FROM t1 LEFT JOIN t2 ON t1.id = t2.id。
应用场景：普通二级索引等值查询。
比如：select * from t2 where key2 =4。
除了唯一索引，我们更多的会使用普通的二级索引。
由于通过二级索引，可能会查询到多个匹配值，相比 const 性能差那么一点。
MySQL 就把这种类型的查询定义为了 ref。
在上面我们说到，由于唯一索引可能存在多个 null，所以用不了 const。
那对于 select * from t2 where key2 is null 来说，不管是唯一索引还是普通索引，其最多用到 ref 这种类型。
应用场景：命中索引时，查询条件除了等值查询，还包含 null 值查询。
比如：select * from t2 where key2 =4 or key2 is null。
其实看名字就很容易理解，MySQL 会在 B + 树上，找到 key2= 1 和 key2 is null 这两种记录范围值，然后拿到主键 id 去回表查询相关信息。
应用场景：查询条件可以命中多个索引的情况。
比如：select * from t3 where key1 =3 or key2 =4、
索引合并其实也很好理解，当查询条件可以命中多个索引时，MySQL 会尝试在两个索引树查找匹配的条件，然后将结果其合并起来。
应用场景：查询条件包含子查询，并且子查询的列可以进行主键等值匹配。
比如：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 (
应用场景：查询条件包含子查询，并且子查询的列可以通过索引进行等值匹配。
比如：SELECT * FROM t2 WHERE t2.key2 IN (SELECT key1 FROM t3 WHERE t2.key2 = t3.key2) OR t2.key2 = 1。
index_subquery 和 unique_subquery 的区别在于子查询中的列是唯一索引还是普通的二级索引。
应用场景：命中索引时，查询某一个范围内的结果。
比如：select * from t3 where t3.key1 >1 and t3.key1<3。
在实际的业务场景中，对某个列进行范围查询还是很常见的需求。
应用场景：直接在某个索引树上做条件判断，并且不需要回表。
比如：select t3.key1 from t3 where t3.key2 =6。
当我们创建了联合索引 idx_key1_key2(key1,key2) 时，判断条件 key2= 6 时，其虽然不满足索引的最左前缀原则，但是我们可以遍历 idx_key1_key2 这颗索引树，找到 key2= 6 的记录即可。
由于查询结果需要的 key1 在这个联合索引上，也不需要回表，此时就可以使用 index。
相对来说，index 的性能是比较慢的。
应用场景：直接遍历整个聚簇索引。
比如：select * from t1。
当 MySQL 无法通过 where 条件匹配到合适的索引或者因为全部扫描的代价更小时，MySQL 就会选择 all 这种类型来全表扫描。
这种方式也是最不推荐的。
总得来说，我们在进行查询时，查询类型可分为两大类：全部扫描和索引查询。
索引查询又可以细分：
唯一索引等值查询。
普通索引等值查询。
普通索引范围查询。
扫描整个索引树。
对于一条查询 sql 来说，不同的查询类型虽然结果可能是一样的，但是其性能却可能天差地别。
不同类型性能从强到差：system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > all。
建议大家在平时书写 sql 时，多用 explain 进行分析，尝试去优化代码，只有不断的实践，才能让自己的 sql 能力越来越强。
