今天主要先容如何通过 explain 命令获取 select 语句的实行操持,通过 explain 我们可以知道以下信息:表的读取顺序,数据读取操作的类型,哪些索引可以利用,哪些索引实际利用了,表之间的引用,每张表有多少行被优化器查询等信息。
explain例子在 select 语句之前增加 explain 关键字,MySQL 会在查询上设置一个标记,实行查询时,会返回实行操持的信息,而不是实行这条SQL(如果 from 中包含子查询,仍会实行该子查询,将结果放入临时表中)。
expain出来的信息紧张关注10列,分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra,下面对这些字段涌现的可能进行阐明。

id
我的理解是SQL实行的顺序的标识,SQL从大到小的实行
1. id相同时,实行顺序由上至下
2. 如果是子查询,id的序号会递增,id值越大优先级越高,越先被实行
3.id如果相同,可以认为是一组,从上往下顺序实行;在所有组中,id值越大,优先级越高,越先实行
select_type表示查询中每个select子句的类型
(1) SIMPLE(大略SELECT,不该用UNION或子查询等)
(2) PRIMARY(查询中若包含任何繁芜的子部分,最外层的select被标记为PRIMARY)
(3) UNION(UNION中的第二个或后面的SELECT语句)
(4) DEPENDENT UNION(UNION中的第二个或后面的SELECT语句,取决于表面的查询)
(5) UNION RESULT(UNION的结果)
(6) SUBQUERY(子查询中的第一个SELECT)
(7) DEPENDENT SUBQUERY(子查询中的第一个SELECT,取决于表面的查询)
(8) DERIVED(派生表的SELECT, FROM子句的子查询)
(9) UNCACHEABLE SUBQUERY(一个子查询的结果不能被缓存,必须重新评估外链接的第一行)
table显示这一行的数据是关于哪张表的,有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步实行的结果)
mysql> explain select from (select from ( select from t1 where id=2602) a) b;+----+-------------+------------+--------+-------------------+---------+---------+---| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra|| 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | | 2 | DERIVED | <derived3> | system | NULL | NULL | NULL | NULL | 1 | | 3 | DERIVED | t1 | const | PRIMARY,idx_t1_id | PRIMARY | 4 | | 1 | type
表示MySQL在表中找到所需行的办法,又称“访问类型”。
常用的类型有: ALL, index, range, ref, eq_ref, const, system, NULL(从左到右,性能从差到好)
ALL:Full Table Scan, MySQL将遍历全表以找到匹配的行
index: Full Index Scan,index与ALL差异为index类型只遍历索引树
range:只检索给定例模的行,利用一个索引来选择行
ref: 表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值
eq_ref: 类似ref,差异就在利用的索引是唯一索引,对付每个索引键值,表中只有一条记录匹配,大略来说,便是多表连接中利用primary key或者 unique key作为关联条件
const、system: 当MySQL对查询某部分进行优化,并转换为一个常量时,利用这些类型访问。如将主键置于where列表中,MySQL就能将该查询转换为一个常量,system是const类型的特例,当查询的表只有一行的情形下,利用system
NULL: MySQL在优化过程等分解语句,实行时乃至不用访问表或索引,例如从一个索引列里选取最小值可以通过单独索引查找完成。
possible_keys指出MySQL能利用哪个索引在表中找到记录,查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询利用
该列完备独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按天生的表次序利用。
如果该列是NULL,则没有干系的索引。在这种情形下,可以通过检讨WHERE子句看是否它引用某些列或适宜索引的列来提高你的查询性能。如果是这样,创造一个适当的索引并且再次用EXPLAIN检讨查询
Keykey列显示MySQL实际决定利用的键(索引)
如果没有选择索引,键是NULL。要想逼迫MySQL利用或忽略possible_keys列中的索引,在查询中利用FORCE INDEX、USE INDEX或者IGNORE INDEX。
key_len表示索引中利用的字节数,可通过该列打算查询中利用的索引的长度(key_len显示的值为索引字段的最大可能长度,并非实际利用长度,即key_len是根据表定义打算而得,不是通过表内检索出的)
不丢失精确性的情形下,长度越短越好
ref表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值
rows表示MySQL根据表统计信息及索引选用情形,估算的找到所需的记录所须要读取的行数
Extra该列包含MySQL办理查询的详细信息,有以下几种情形:
Using where:列数据是从仅仅利用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的要求列都是同一个索引的部分的时候,表示mysql做事器将在存储引擎检索行后再进行过滤
Using temporary:表示MySQL须要利用临时表来存储结果集,常见于排序和分组查询
Using filesort:MySQL中无法利用索引完成的排序操作称为“文件排序”
Using join buffer:改值强调了在获取连接条件时没有利用索引,并且须要连接缓冲区来存储中间结果。如果涌现了这个值,那该当把稳,根据查询的详细情形可能须要添加索引来改进能。
Impossible where:这个值强调了where语句会导致没有符合条件的行。
Select tables optimized away:这个值意味着仅通过利用索引,优化器可能仅从聚合函数结果中返回一行
总结• EXPLAIN不会见告你关于触发器、存储过程的信息或用户自定义函数对查询的影响情形
• EXPLAIN不考虑各种Cache
• EXPLAIN不能显示MySQL在实行查询时所作的优化事情
• 部分统计信息是估算的,并非精确值
• EXPALIN只能阐明SELECT操作,其他操作要重写为SELECT后查看实行操持。
后面会分享更多devops和DBA方面的内容,感兴趣的朋友可以关注下!