夜深,最近在写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、>、<这样的查询条件,当MySQL使用索引去查找一系列值时,例如IN和OR时,也会显示RANGE。
- 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查询语句的执行顺序解析
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/5936.html