背景

做开发的都知道， 大部分应用程序主要是读取数据，而写入数据的情况相对较少。

搞优化的都知道，大部分时候，性能瓶颈都是在数据库，优化性能的都是做SQL查询优化。

开发的最后一公里都是在做数据的优化，今天我们就来讲讲优化SQL的，怎么知道优化后的性能。

望闻听切

博大精深的中医在给人看病之前需要通过望闻听切来判断病人的病情，那么查看SQL的性能，我们则需要用EXPLAIN来分析查询语句的性能。

通过执行EXPLAIN，我们可以了解Mysql如何处理查询语句，包括如何使用索引、如何扫描行等。通过分析EXPLAIN结果中type类型，我们可以找出查询中的瓶颈，并进行针对性的优化。

放码过来

1 测试表结构如下，数据1000条

2 type 为null，性能最好，不需要访问表或者索引，直接得到结果。避免了对表的访问和索引的使用，减少了IO操作和数据传输的开销。

解释： 此SQL的目的是查询ID为null的数据，因为这个表设计的ID是为非空的主键，所以不 查询表就知道没有结果，所以此类型可以迅速判断，查询的结果就是没有记录。

生活也一样：太快拿到结果基本都是没有结果。

3 type = const/system ，通过主键查询，只有唯一的一条数据

4 type = eq_ref，当EXPLAIN的type字段为eq_ref时，表示使用了等值连接，并且使用了一个索引来访问表中的数据。eq_ref通常用于连接两个表，并且连接条件是使用主键或唯一索引的列。

5 type = ref，使用非唯一性索引或者唯一索引的前缀扫描，返回匹配某个单独值的记录行

6 type = range ，索引范围扫描，常见于<、<=、>、>=、between等操作符

由于需要扫描索引的多个块，range操作通常比ref更慢。

7 type = index，索引全扫描，只遍历索引树

总结

常见的索引性能分析结果就是这几种，其他的复杂点的放到后面讲，包含以下几种：

fulltext: 全文索引访问，index_merge: 索引合并优化方法

unique_subquery: 类似于eq_ref，index_subquery: 类似于ref，区别就在使用的是子查询。