夜深，最近在写SQL优化的一些文章，看到私聊中，有很多人在问如何判断是否需要优化或者是如何查看MySQL执行计划，本文简要介绍一下MySQL EXPLAIN命令。

EXPLAIN命令是查看优化器如何决定执行查询的主要方法。通常，我们查看执行计划获取以下信息：

• SQL如何使用索引
• 联接查询的执行顺序
• 查询扫描的数据行数
• 哪些索引可以使用
• 哪些索引被实际使用

MySQL Explain语法

如下

执行计划包含的信息

ID 说明

表示执行SELECT语句的顺序，ID相同时，执行顺序由上至下。如果是子查询，ID的序号会递增，ID越大优先级越高，越优先被执行。

SELECT_TYPE说明

• SIMPLE：简单查询，即不包含子查询或是UNION操作的查询。
• PRIMARY：最外层查询，即查询中包含任何子查询，则最外层的查询则被标记为PRIMARY。
• SUBQUERY：映射为子查询，即在SELECT 或 WHERE列表中包含了子查询 。
• DEPENDENT SUBQUERY：依赖外部结果的子查询。
• DERIVED：子查询，即出现在FROM子句中的子查询。
• UNION：联合，若第二个SELECT出现在UNION之后，则被标记为UNION。若UNION包含在FROM子句的子查询中，外层SELECT将被标记为DERIVED。
• UNION RESULT：使用联合的结果，即UNION产生的结果集。

TABLE 说明

指的就是当前执行的表，即输出数据行所在的表的名称。由ID为M,N查询union产生的结果集，或者是由ID为N的查询产生的结果。

TYPE 说明

• ALL：全数据表扫描 ，遍历全表以找到匹配的行，效率最差。
• INDEX：全索引表扫描，INDEX与ALL区别为index类型只遍历索引树。
• RANGE：对索引列进行范围查找，只检索给定范围的行，使用一个索引来选择行，常见于BETWEEN、>、
• INDEX_MERGE：合并索引，使用多个单列索引搜索。
• REF：使用非唯一索引扫描或者唯一索引的前缀扫描，返回匹配某个单独值的数据行，然而他可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体 。
• EQ_REF：唯一性索引扫描，对于每个索引键，表中只有一条数据与之匹配。常见于主键 或 唯一索引扫描。
• CONST：表中有且只有一个匹配的行时使用。因为仅有一行，在这行的列值可被优化器剩余部分认为是常数，如对主键或是唯一索引的查询，效率最高的联接方式。
• SYSTEM：SYSTEM是CONST类型的特例，即当查询的表只有一行的情况下(等于系统表)。
• NULL: MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成。

性能排序如下：

一般来说，得保证查询至少达到RANGE级别，最好能达到REF。

POSSIBLE_KEYS 说明

可能使用的索引，指出MySQL能使用哪些索引来优化查询，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。

KEY 说明

KEY 列显示MySQL实际决定使用的索引，如果没有可用的索引，则显示为NULL。如查询使用了覆盖索引，则该索引仅出现在Key列中。要想强制MySQL使用或忽视POSSIBLE_KEYS 列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

KEY_LEN 说明

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度，KEY_LEN 显示的值为索引字段的最大可能长度，理论上长度越短越好，但并非实际使用长度，即KEY_LEN 是根据表定义计算而得，而不是通过表内检索出的。

REF 说明

表示上述表的连接匹配条件，即表示哪些列或常量被用于查找索引列上的值。

ROWS 说明

表示MySQL根据表统计信息及索引选用情况，估算的找到所需的数据所需要读取的行数，ROWS值的大小是个统计抽样结果，并不完全准确。

Extra 说明

不适合在其他列中显示，但又很重要的额外信息，有以下几种情况：

• using index：使用了覆盖索引(Covering Index)进行查询，以避免访问表。
• using where：MySQL将在存储引擎检索行后再进行过滤。许多WHERE条件里涉及索引中的列，当它读取索引时，就能被存储引擎检验，因此不是所有带WHERE子句的查询都会显示"using where"。
• using temporary：MySQL需要使用临时表来存储结果集，常见于排序、子查询和分组查询。
• using filesort：MySQL中无法利用索引完成的排序操作称为文件排序。MySQL有两种文件排序方式，都可以在内存或者磁盘上完成， 通常会出现在ORDER BY或GROUP BY查询中。
• not exists：使用Not Exists来优化查询。
• select tables optimized away：直接通过索引来获取数据，不用访问表。
• Using join buffer：表示在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，应该注意，根据查询的具体情况可能需要添加索引来改进性能。

引发索引失效，导致全表扫描的原因有：

• 索引列进行计算、函数、类型转换等操作。
• 索引列使用不等于，如!= 或<>。
• 索引列使用 IS NULL ，IS NOT NULL。
• 模糊查询LIKE 以通配符开头如，%ab。
• 索引列使用使用 OR 来连接条件。
• 索引列使用IN 和 NOT IN 。
• 隐式转换，类型错误，如字段NUM类型为varchar，WHERE条件用number，NUM = 1。
• WHERE子句和ORDER BY使用相同的索引，并且ORDER BY的顺序和索引顺序相同，并且ORDER BY的字段都是升序或者降序，否则不会使用索引。
• 复合索引不符合最佳左前缀原则或存在断点。
• 如果MYSQL评估使用索引比全表扫描更慢，则不使用索引。

索引失效优化技巧

可阅读：日拱一卒，SQL语法优化方法及实例详解

SQL 执行顺序

可阅读：SQL查询语句的执行顺序解析