使用EXPLAIN关键字能够模拟优化器执行SQL查询语句,从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。如何使用索引来处理select语句以及链接表。能够帮助选择更好的索引和写出更优化的查询语句。mysql
经过EXPLAIN,咱们能够分析出如下结果:sql
使用方式以下:express
EXPLAIN +SQL语句
执行计划包含的信息 函数
+----+-------------+---------+------+---------------+------+---------+------+--------+----------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+---------+------+---------------+------+---------+------+--------+----------+-------+
执行计划各字段含义:性能
id | SELECT识别符。这是SELECT的查询序列号 |
select_type | SELECT类型,能够为如下任何一种:优化
|
table | 输出的行所引用的表 (指的就是当前执行的表)spa |
type | 联接类型。下面给出各类联接类型,按照从最佳类型到最坏类型进行排序:设计
|
possible_keys | 指出MySQL能使用哪一个索引在该表中找到行指针 |
key | 显示MySQL实际决定使用的键(索引)。若是没有选择索引,键是NULL。 |
key_len | 显示MySQL决定使用的键长度。若是键是NULL,则长度为NULL。 |
ref | 显示使用哪一个列或常数与key一块儿从表中选择行。 |
rows | 显示MySQL认为它执行查询时必须检查的行数。多行之间的数据相乘能够估算要处理的行数。 |
filtered | 显示了经过条件过滤出的行数的百分比估计值。 |
Extra | 该列包含MySQL解决查询的详细信息code
|
select查询的序列号,包含一组数字,表示查询中执行select子句或操做表的顺序
id的结果共有3中状况
1. id相同,执行顺序由上至下 2. id不一样,若是是子查询,id的序号会递增,id值越大优先级越高,越先被执行 3. id相同不一样,同时存在
1. id相同,执行顺序由上至下
2. id不一样,若是是子查询,id的序号会递增,id值越大优先级越高,越先被执行
3. id相同不一样,同时存在 ,如图,
如上图所示,在id为1时,table显示的是 <derived2>
,这里指的是指向id为2的表,即t3表的衍生表。
常见和经常使用的值有以下几种:
分别用来表示查询的类型,主要是用于区别普通查询、联合查询、子查询等的复杂查询。
- SIMPLE 简单的select查询,查询中不包含子查询或者UNION - PRIMARY 查询中若包含任何复杂的子部分,最外层查询则被标记为PRIMARY - SUBQUERY 在SELECT或WHERE列表中包含了子查询 - DERIVED 在FROM列表中包含的子查询被标记为DERIVED(衍生),MySQL会递归执行这些子查询,把结果放在临时表中 - UNION 若第二个SELECT出如今UNION以后,则被标记为UNION:若UNION包含在FROM子句的子查询中,外层SELECT将被标记为:DERIVED - UNION RESULT 从UNION表获取结果的SELECT
1. UNION
当经过union来链接多个查询结果时,第二个以后的select其select_type为UNION。
mysql> explain select * from t_order where order_id=100 union select * from t_order where order_id=200; +----+--------------+------------+-------+---------------+---------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------+------------+-------+---------------+---------+---------+-------+------+-------+ | 1 | PRIMARY | t_order | const | PRIMARY | PRIMARY | 4 | const | 1 | | | 2 | UNION | t_order | const | PRIMARY | PRIMARY | 4 | const | 1 | | | NULL | UNION RESULT | <union1,2> | ALL | NULL | NULL | NULL | NULL | NULL | | +----+--------------+------------+-------+---------------+---------+---------+-------+------+-------+
2.DEPENDENT UNION与DEPENDENT SUBQUERY:
当union做为子查询时,其中第二个union的select_type就是DEPENDENT UNION。
第一个子查询的select_type则是DEPENDENT SUBQUERY。
mysql> explain select * from t_order where order_id in (select order_id from t_order where order_id=100 union select order_id from t_order where order_id=200); +----+--------------------+------------+-------+---------------+---------+---------+-------+--------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+------------+-------+---------------+---------+---------+-------+--------+-------------+ | 1 | PRIMARY | t_order | ALL | NULL | NULL | NULL | NULL | 100453 | Using where | | 2 | DEPENDENT SUBQUERY | t_order | const | PRIMARY | PRIMARY | 4 | const | 1 | Using index | | 3 | DEPENDENT UNION | t_order | const | PRIMARY | PRIMARY | 4 | const | 1 | Using index | | NULL | UNION RESULT | <union2,3> | ALL | NULL | NULL | NULL | NULL | NULL | | +----+--------------------+------------+-------+---------------+---------+---------+-------+--------+-------------+
3.SUBQUERY:
子查询中的第一个select其select_type为SUBQUERY。
mysql> explain select * from t_order where order_id=(select order_id from t_order where order_id=100); +----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+ | 1 | PRIMARY | t_order | const | PRIMARY | PRIMARY | 4 | const | 1 | | | 2 | SUBQUERY | t_order | const | PRIMARY | PRIMARY | 4 | | 1 | Using index | +----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+
4.DERIVED:
当子查询是from子句时,其select_type为DERIVED。
mysql> explain select * from (select order_id from t_order where order_id=100) a; +----+-------------+------------+--------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+--------+---------------+---------+---------+------+------+-------------+ | 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | | | 2 | DERIVED | t_order | const | PRIMARY | PRIMARY | 4 | | 1 | Using index | +----+-------------+------------+--------+---------------+---------+---------+------+------+-------------+
type所显示的是查询使用了哪一种类型,type包含的类型包括以下图所示的几种:
从最好到最差依次是:
system > const > eq_ref > ref > range > index > all
通常来讲,得保证查询至少达到range级别,最好能达到ref。
1.system,const
system
表只有一行记录(等于系统表),这是const类型的特列,平时不会出现,这个也能够忽略不计
const
表示经过索引一次就找到了,const用于比较primary key 或者unique索引。由于只匹配一行数据,因此很快。如将主键置于where列表中,MySQL就能将该查询转换为一个常量。
首先进行子查询获得一个结果的d1临时表,子查询条件为id = 1 是常量,因此type是const,id为1的至关于只查询一条记录,因此type为system。
2.eq_ref
eq_ref
惟一性索引扫描,对于每一个索引键,表中只有一条记录与之匹配。常见于主键或惟一索引扫描
在t_order表中的order_id是主键,t_order_ext表中的order_id也是主键,该表能够认为是订单表的补充信息表,他们的关系是1对1,在下面的例子中能够看到b表的链接类型是eq_ref,这是极快的联接类型。
mysql> explain select * from t_order a,t_order_ext b where a.order_id=b.order_id; +----+-------------+-------+--------+---------------+---------+---------+-----------------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------+---------+---------+-----------------+------+-------------+ | 1 | SIMPLE | b | ALL | order_id | NULL | NULL | NULL | 1 | | | 1 | SIMPLE | a | eq_ref | PRIMARY | PRIMARY | 4 | test.b.order_id | 1 | Using where | +----+-------------+-------+--------+---------------+---------+---------+-----------------+------+-------------+
3.ref
ref
非惟一性索引扫描,返回匹配某个单独值的全部行,本质上也是一种索引访问,它返回全部匹配某个单独值的行,然而,它可能会找到多个符合条件的行,因此他应该属于查找和扫描的混合体。
下面的例子在上面的例子上略做了修改,加上了条件。此时b表的联接类型变成了ref。由于全部与a表中order_id=100的匹配记录都将会从b表获取。这是比较常见的联接类型。
mysql> explain select * from t_order a,t_order_ext b where a.order_id=b.order_id and a.order_id=100; +----+-------------+-------+-------+---------------+----------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+----------+---------+-------+------+-------+ | 1 | SIMPLE | a | const | PRIMARY | PRIMARY | 4 | const | 1 | | | 1 | SIMPLE | b | ref | order_id | order_id | 4 | const | 1 | | +----+-------------+-------+-------+---------------+----------+---------+-------+------+-------+
4.ref_or_null
user_id字段是一个能够为空的字段,并对该字段建立了一个索引。在下面的查询中能够看到联接类型为ref_or_null,这是mysql为含有null的字段专门作的处理。在咱们的表设计中应当尽可能避免索引字段为NULL,由于这会额外的耗费mysql的处理时间来作优化。
mysql> explain select * from t_order where user_id=100 or user_id is null; +----+-------------+---------+-------------+---------------+---------+---------+-------+-------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------------+---------------+---------+---------+-------+-------+-------------+ | 1 | SIMPLE | t_order | ref_or_null | user_id | user_id | 5 | const | 50325 | Using where | +----+-------------+---------+-------------+---------------+---------+---------+-------+-------+-------------+
5.index_merge
常常出如今使用一张表中的多个索引时。mysql会将多个索引合并在一块儿,以下例:
mysql> explain select * from t_order where order_id=100 or user_id=10; +----+-------------+---------+-------------+-----------------+-----------------+---------+------+------+-------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------------+-----------------+-----------------+---------+------+------+-------------------------------------------+ | 1 | SIMPLE | t_order | index_merge | PRIMARY,user_id | PRIMARY,user_id | 4,5 | NULL | 2 | Using union(PRIMARY,user_id); Using where | +----+-------------+---------+-------------+-----------------+-----------------+---------+------+------+-------------------------------------------+
6.unique_subquery
该联接类型用于替换value IN (SELECT primary_key FROM single_table WHERE some_expr)这样的子查询的ref。注意ref列,其中第二行显示的是func,代表unique_subquery是一个函数,而不是一个普通的ref。
mysql> explain select * from t_order where order_id in (select order_id from t_order where user_id=10); +----+--------------------+---------+-----------------+-----------------+---------+---------+------+--------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+---------+-----------------+-----------------+---------+---------+------+--------+-------------+ | 1 | PRIMARY | t_order | ALL | NULL | NULL | NULL | NULL | 100649 | Using where | | 2 | DEPENDENT SUBQUERY | t_order | unique_subquery | PRIMARY,user_id | PRIMARY | 4 | func | 1 | Using where | +----+--------------------+---------+-----------------+-----------------+---------+---------+------+--------+-------------+
7.index_subquery
该联接类型与上面的太像了,惟一的差异就是子查询查的不是主键而是非惟一索引。
mysql> explain select * from t_order where user_id in (select user_id from t_order where order_id>10); +----+--------------------+---------+----------------+-----------------+---------+---------+------+--------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+---------+----------------+-----------------+---------+---------+------+--------+--------------------------+ | 1 | PRIMARY | t_order | ALL | NULL | NULL | NULL | NULL | 100649 | Using where | | 2 | DEPENDENT SUBQUERY | t_order | index_subquery | PRIMARY,user_id | user_id | 5 | func | 50324 | Using index; Using where | +----+--------------------+---------+----------------+-----------------+---------+---------+------+--------+--------------------------+
8.range
range
只检索给定范围的行,使用一个索引来选择行,key列显示使用了哪一个索引,通常就是在你的where语句中出现between、< 、>、in等的查询,这种范围扫描索引比全表扫描要好,由于它只须要开始于索引的某一点,而结束于另外一点,不用扫描所有索引。
按指定的范围进行检索,很常见。
mysql> explain select * from t_order where user_id in (100,200,300); +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+ | 1 | SIMPLE | t_order | range | user_id | user_id | 5 | NULL | 3 | Using where | +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
9.index
index
Full Index Scan,Index与All区别为index类型只遍历索引树。这一般比ALL快,由于索引文件一般比数据文件小。(也就是说虽然all和Index都是读全表,但index是从索引中读取的,而all是从硬盘读取的)
在进行统计时很是常见,此联接类型实际上会扫描索引树,仅比ALL快些。
mysql> explain select count(*) from t_order; +----+-------------+---------+-------+---------------+---------+---------+------+--------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+---------+---------+------+--------+-------------+ | 1 | SIMPLE | t_order | index | NULL | user_id | 5 | NULL | 100649 | Using index | +----+-------------+---------+-------+---------------+---------+---------+------+--------+-------------+
10.ALL
all
Full Table Scan 将遍历全表以找到匹配的行
完整的扫描全表,最慢的联接类型,尽量的避免。
mysql> explain select * from t_order; +----+-------------+---------+------+---------------+------+---------+------+--------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+--------+-------+ | 1 | SIMPLE | t_order | ALL | NULL | NULL | NULL | NULL | 100649 | | +----+-------------+---------+------+---------------+------+---------+------+--------+-------+
possible_keys
显示可能应用在这张表中的索引,一个或多个。查询涉及到的字段上若存在索引,则该索引将被列出,但不必定被查询实际使用。
key
explain select * from tb;
表示索引中使用的字节数,可经过该列计算查询中使用的索引的长度,在不损失精确性的状况下,长度越短越好
。key_len显示的值为索引字段的最大可能长度,并不是实际使用长度,即key_len是根据表定义计算而得,不是经过表内检索出的。
显示索引的那一列被使用了,若是可能的话,最好是一个常数。哪些列或常量被用于查找索引列上的值。
三.extra的说明
1.Distinct
MySQL发现第1个匹配行后,中止为当前的行组合搜索更多的行。对于此项没有找到合适的例子,求指点。
2.Not exists
由于b表中的order_id是主键,不可能为NULL,因此mysql在用a表的order_id扫描t_order表,并查找b表的行时,若是在b表发现一个匹配的行就再也不继续扫描b了,由于b表中的order_id字段不可能为NULL。这样避免了对b表的屡次扫描。
mysql> explain select count(1) from t_order a left join t_order_ext b on a.order_id=b.order_id where b.order_id is null; +----+-------------+-------+-------+---------------+--------------+---------+-----------------+--------+--------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+--------------+---------+-----------------+--------+--------------------------------------+ | 1 | SIMPLE | a | index | NULL | express_type | 1 | NULL | 100395 | Using index | | 1 | SIMPLE | b | ref | order_id | order_id | 4 | test.a.order_id | 1 | Using where; Using index; Not exists | +----+-------------+-------+-------+---------------+--------------+---------+-----------------+--------+--------------------------------------+
3.Range checked for each record
这种状况是mysql没有发现好的索引可用,速度比没有索引要快得多。
mysql> explain select * from t_order t, t_order_ext s where s.order_id>=t.order_id and s.order_id<=t.order_id and t.express_type>5; +----+-------------+-------+-------+----------------------+--------------+---------+------+------+------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+----------------------+--------------+---------+------+------+------------------------------------------------+ | 1 | SIMPLE | t | range | PRIMARY,express_type | express_type | 1 | NULL | 1 | Using where | | 1 | SIMPLE | s | ALL | order_id | NULL | NULL | NULL | 1 | Range checked for each record (index map: 0x1) | +----+-------------+-------+-------+----------------------+--------------+---------+------+------+------------------------------------------------+
4.Using filesort
在有排序子句的状况下很常见的一种状况。此时mysql会根据联接类型浏览全部符合条件的记录,并保存排序关键字和行指针,而后排序关键字并按顺序检索行。
mysql> explain select * from t_order order by express_type; +----+-------------+---------+------+---------------+------+---------+------+--------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+--------+----------------+ | 1 | SIMPLE | t_order | ALL | NULL | NULL | NULL | NULL | 100395 | Using filesort | +----+-------------+---------+------+---------------+------+---------+------+--------+----------------+
5.Using index
这是性能很高的一种状况。当查询所需的数据能够直接从索引树中检索到时,就会出现。上面的例子中有不少这样的例子,再也不多举例了。
6.Using temporary
发生这种状况通常都是须要进行优化的。mysql须要建立一张临时表用来处理此类查询。
mysql> explain select * from t_order a left join t_order_ext b on a.order_id=b.order_id group by b.order_id; +----+-------------+-------+------+---------------+----------+---------+-----------------+--------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+----------+---------+-----------------+--------+---------------------------------+ | 1 | SIMPLE | a | ALL | NULL | NULL | NULL | NULL | 100395 | Using temporary; Using filesort | | 1 | SIMPLE | b | ref | order_id | order_id | 4 | test.a.order_id | 1 | | +----+-------------+-------+------+---------------+----------+---------+-----------------+--------+---------------------------------+
7.Using where
当有where子句时,extra都会有说明。
8.Using sort_union(...)/Using union(...)/Using intersect(...)
下面的例子中user_id是一个检索范围,此时mysql会使用sort_union函数来进行索引的合并。而当user_id是一个固定值时,请参看上面type说明5.index_merge的例子,此时会使用union函数进行索引合并。
mysql> explain select * from t_order where order_id=100 or user_id>10; +----+-------------+---------+-------------+-----------------+-----------------+---------+------+------+------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------------+-----------------+-----------------+---------+------+------+------------------------------------------------+ | 1 | SIMPLE | t_order | index_merge | PRIMARY,user_id | user_id,PRIMARY | 5,4 | NULL | 2 | Using sort_union(user_id,PRIMARY); Using where | +----+-------------+---------+-------------+-----------------+-----------------+---------+------+------+------------------------------------------------+
对于Using intersect的例子能够参看下例,user_id与express_type发生了索引交叉合并。
mysql> explain select * from t_order where express_type=1 and user_id=100; +----+-------------+---------+-------------+----------------------+----------------------+---------+------+------+----------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------------+----------------------+----------------------+---------+------+------+----------------------------------------------------+ | 1 | SIMPLE | t_order | index_merge | user_id,express_type | user_id,express_type | 5,1 | NULL | 1 | Using intersect(user_id,express_type); Using where | +----+-------------+---------+-------------+----------------------+----------------------+---------+------+------+----------------------------------------------------+
9.Using index for group-by
代表能够在索引中找到分组所需的全部数据,不须要查询实际的表。
mysql> explain select user_id from t_order group by user_id; +----+-------------+---------+-------+---------------+---------+---------+------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+---------+---------+------+------+--------------------------+ | 1 | SIMPLE | t_order | range | NULL | user_id | 5 | NULL | 3 | Using index for group-by | +----+-------------+---------+-------+---------------+---------+---------+------+------+--------------------------+
除了上面的三个说明,还须要注意rows的数值,多行之间的数值是乘积的关系,能够估算大概要处理的行数,若是乘积很大,那就颇有优化的必要了。