MySQL EXPLAIN SQL 输出信息描述

    EXPLAIN语句能够被用于获取一些关于SQL执行时的相关信息,比如表的连接顺序,对表的方式方式等等。通过对该相关信息进行进一步的分析,我们
    可以通过对表添加适当的索引,以及优化连接顺序,使用提示等等手段来达到使SQL高效运行的目的。本文描述了EXPLAIN的用法并给出了相关示例。

一、EXPLAIN概述

EXPLAIN 语句主要是用于解析SQL执行计划,通过分析执行计划采取适当的优化方式提高SQL运行的效率。
EXPLAIN 语句输出通常包括id列,select_type,table,type,possible_keys,key等等列信息
MySQL 5.6.3后支持SELECT, DELETE, INSERT,REPLACE, and UPDATE.
EXPLAIN EXTENDED支持一些额外的执行计划相关的信息
EXPLAIN PARTITIONS支持基于分区表查询执行计划的相关信息

二、EXPLAIN输出列描述

-- 下面通过示例来展示EXPLAIN输出列
([email protected]) [sakila]> explain select sum(amount) from customer a,
    -> payment b where 1=1 and a.customer_id=b.customer_id and
    -> email=‘[email protected]‘\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: a
         type: ALL
possible_keys: PRIMARY
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 590
        Extra: Using where
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: b
         type: ref
possible_keys: idx_fk_customer_id
          key: idx_fk_customer_id
      key_len: 2
          ref: sakila.a.customer_id
         rows: 14
        Extra: 

1、各列表示的意义

Column        Meaning
------        ------------------------------------
id            The SELECT identifier
select_type   The SELECT type
table         The table for the output row
partitions    The matching partitions
type          The join type
possible_keys The possible indexes to choose
key           index actually chosen
key_len       The length of the chosen key
ref           The columns compared to the index
rows          Estimate of rows to be examined
filtered      Percentage of rows filtered by table condition
Extra         Additional information

2、各列上的具体描述

id:
    包含一组数字,表示查询中执行select子句或操作表的顺序
    id相同,执行顺序由上至下,否则id值越大(通常子查询会产生)优先级越高,越先被执行
    id如果相同,可以认为是一组,从上往下顺序执行;在所有组中,id值越大,优先级越高,越先执行

select_type:
    表示查询中每个select子句的类型(简单 OR复杂)
    select_type              Value Meaning
    -------------            -----------------------------------------------
    SIMPLE                   Simple SELECT (not using UNION or subqueries)
    PRIMARY                  Outermost SELECT 最外层select
    UNION                    Second or later SELECT statement in a UNION
    DEPENDENT UNION          Second or later SELECT statement in a UNION, dependent on outer query
    UNION                    RESULT Result of a UNION.
    SUBQUERY                 First SELECT in subquery
    DEPENDENT SUBQUERY       First SELECT in subquery, dependent on outer query(通常为相关子查询)
    DERIVED                  Derived table SELECT (subquery in FROM clause)
    MATERIALIZED             Materialized subquery
    UNCACHEABLE SUBQUERY     A subquery for which the result cannot be cached and must be reevaluated
                             for each row of the outer query
    UNCACHEABLE UNION        The second or later select in a UNION that belongs to an uncacheable
                             subquery (see UNCACHEABLE SUBQUERY)    

table:
    从哪个表(表名)上输出行记录,也可能是下列值:
    ? <unionM,N>: The row refers to the union of the rows with id values of M and N.
    ? <derivedN>: The row refers to the derived table result for the row with an id value of N.
                  A derived table may result, for example, from a subquery in the FROM clause.
    ? <subqueryN>: The row refers to the result of a materialized subquery for the row with an id value of N. 

partitions:
    查询匹配的记录来自哪一个分区,当使用EXPLAIN,分区PARTITIONS关键字被指定时

type:
    连接类型
    system          表只有一行
    const           表最多只有一行匹配,通用用于主键或者唯一索引比较时
    eq_ref          每次与之前的表合并行都只在该表读取一行,这是除了system,const之外最好的一种,
                    特点是使用=,而且索引的所有部分都参与join且索引是主键或非空唯一键的索引
    ref             如果每次只匹配少数行,那就是比较好的一种,使用=或<=>,可以是左覆盖索引或非主键或非唯一键
    fulltext        全文搜索
    ref_or_null     与ref类似,但包括NULL
    index_merge     表示出现了索引合并优化(包括交集,并集以及交集之间的并集),但不包括跨表和全文索引。
                    这个比较复杂,目前的理解是合并单表的范围索引扫描(如果成本估算比普通的range要更优的话)
    unique_subquery 在in子查询中,就是value in (select...)把形如“select unique_key_column”的子查询替换。
                    PS:所以不一定in子句中使用子查询就是低效的!
    index_subquery  同上,但把形如”select non_unique_key_column“的子查询替换
    range           常数值的范围
    index           a.当查询是索引覆盖的,即所有数据均可从索引树获取的时候(Extra中有Using Index);
                    b.以索引顺序从索引中查找数据行的全表扫描(无 Using Index);
                    c.如果Extra中Using Index与Using Where同时出现的话,则是利用索引查找键值的意思;
                    d.如单独出现,则是用读索引来代替读行,但不用于查找
    all             全表扫描

possible_keys:
    指出MySQL能使用哪个索引在表中找到行。
    查询涉及到的字段上若存在索引则该索引将被列出,但不一定被查询使用。
    如果改列为NULL,说明该查询不会使用到当前表上的相关索引,考虑是否有必要添加索引

key
    显示MySQL在查询中实际使用的索引,若没有使用索引,显示为NULL
    也可能存在key不等于possible_keys的情形,即possible_keys不适合提取所需的行
    而查询所选择的列在使用其他索引时更高效
    TIPS:查询中若使用了覆盖索引,则该索引仅出现在key列表中

key_len
    表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度

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

rows
    表示MySQL根据表统计信息及索引选用情况,估算的找到所需的记录所需要读取的行数
    对于InnoDB,该值为预估,不一定精确

Extra
    包含不适合在其他列中显示但十分重要的额外信息

三、使用EXPLAIN EXTENDED 示例

([email protected]) [sakila]> explain extended select * from city where country_id in
    -> ( select country_id from country where country=‘China‘) and 1=1 \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: country
         type: ALL
possible_keys: PRIMARY
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 109
     filtered: 100.00
        Extra: Using where
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: city
         type: ref
possible_keys: idx_fk_country_id
          key: idx_fk_country_id
      key_len: 2
          ref: sakila.country.country_id
         rows: 1
     filtered: 100.00
        Extra: NULL
2 rows in set, 1 warning (0.00 sec)

([email protected]) [sakila]> show warnings\G
*************************** 1. row ***************************
  Level: Note
   Code: 1003
Message: /* select#1 */ select `city`.`city_id` AS `city_id`,`city`.`city` AS `city`,`city`.`country_id`
AS `country_id`,`city`.`last_update` AS `last_update` from `sakila`.`country` join `sakila`.`city` where
 ((`city`.`country_id` = `country`.`country_id`) and (`country`.`country` = ‘China‘))
1 row in set (0.00 sec)

-- 从上面的extended使用可以看出,查询中多出了filtered列
-- 其次原来的SQL语句真正在执行的时候被改写,即原来的1=1的条件被去掉
-- 对于复杂的SQL语句我们可以通过该方式获得一个比较清晰的真正被执行的SQL语句

四、EXPLAIN PARTITIONS示例

([email protected]) [sakila]> CREATE TABLE `actor_part` (
    ->   `actor_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
    ->   `first_name` varchar(45) NOT NULL,
    ->   `last_name` varchar(45) NOT NULL,
    ->   `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    ->   PRIMARY KEY (`actor_id`),
    ->   KEY `idx_actor_last_name` (`last_name`)
    -> ) partition by hash(actor_id) partitions 4;
Query OK, 0 rows affected (0.11 sec)

([email protected]) [sakila]> insert into actor_part select * from actor;
Query OK, 200 rows affected (0.02 sec)
Records: 200  Duplicates: 0  Warnings: 0

([email protected]) [sakila]> explain select * from actor_part where actor_id=10;  -- 未使用partitions时
+----+-------------+------------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table      | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+------------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | actor_part | const | PRIMARY       | PRIMARY | 2       | const |    1 | NULL  |
+----+-------------+------------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)

([email protected]) [sakila]> explain partitions select * from actor_part where actor_id=10; -- 使用partitions时
+----+-------------+------------+------------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table      | partitions | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+------------+------------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | actor_part | p2         | const | PRIMARY       | PRIMARY | 2       | const |    1 | NULL  |
+----+-------------+------------+------------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)
-- 多出了partitions列

五、参考:

MySQL reference manual 5.6
其他个人博客

版权声明:本文为博主原创文章,欢迎扩散,扩散请务必注明出处。

时间: 2024-10-22 10:21:04

MySQL EXPLAIN SQL 输出信息描述的相关文章

mysql explain type连接类型示例

对于MySQL执行计划的获取,我们可以通过explain方式来查看,explain方式看似简单,实际上包含的内容很多,尤其是输出结果中的type类型列.理解这些不同的类型,对于我们SQL优化举足轻重,本文仅描述explian输出结果中的type列,同时给出其演示. 有关explian输出的全描述,可以参考:MySQL EXPLAIN SQL 输出信息描述 一.EXPLAIN 语句中type列的值 type: 连接类型 system 表只有一行 const 表最多只有一行匹配,通用用于主键或者唯一

mysql优化sql语句

mysql优化sql语句 常见误区 www.2cto.com 误区1: count(1)和count(primary_key) 优于 count(*) 很多人为了统计记录条数,就使用 count(1) 和 count(primary_key) 而不是 count(*) ,他们认为这样性能更好, 其实这是一个误区.对于有些场景,这样做可能性能会更差,应为数据库对 count(*) 计数操作做了一些特别的优化. 误区2: count(column) 和 count(*) 是一样的 这个误区甚至在很多

mysql explain 分析sql语句

鉴于最近做的事情,需要解决慢sql的问题,现补充一点sql语句性能分析之explain的使用方式! 综合返回数据情况,分析各个参数,可以了解sql 使用方法:explain  + sql语句 如 :explain select id as paid,userid from patientattachments  where id =1000  ORDER BY ctime desc limit 10; 各个属性的含义 id  select查询的序列号 select_type    select查

解析MYsql explain执行计划extra列输出

EXPLAIN Extra 列信息: explain Extra列输出包含了关于mysql如何解决query的额外信息,特别是出现Using filesort 和 using temporary时,应当格外注意: 1:Child of  'table' pushed [email protected] 在做join时下推到NDB存储引擎中,引用子表‘table’,当下推join支持时,应用与Mysql cluster: 2: const row not found 通过一个query sql 例

Mysql explain分析SQL语句之字段属性说明

在 explain的帮助下,您就知道什么时候该给表添加索引,以使用索引来查找记录从而让select 运行更快.如果由于不恰当使用索引而引起一些问题的话,可以运行 analyze table来更新该表的统计信息,例如键的基数,它能帮您在优化方面做出更好的选择. explain 返回了一行记录,它包括了 select语句中用到的各个表的信息.这些表在结果中按照mysql即将执行的查询中读取的顺序列出来.mysql用一次扫描多次连接(single- sweep,multi-join)的方法来解决连接.

退役笔记一#MySQL = lambda sql : sql + &#39; Source Code 4 Explain Plan &#39;

Mysql 查询执行过程 大致分为4个阶段吧: 语法分析(sql_parse.cc<词法分析, 语法分析, 语义检查 >) >>sql_resolver.cc # JOIN.prepare 生成逻辑查询plan(sql_optimizer.cc) >># JOIN.optimize 生成物理查询plan(sql_planner.cc) run the explain plan(sql_executor.cc) 退役笔记一#MySQL = lambda sql : sql

ibatis配置log4j输出sql日志信息

为了在开发过程更加直观,我们需要将ibatis日志打开以便观察ibatis运作的细节. ibatis采用Apache common_logging,并结合Apache log4j作为日志输出组件. 在CLASSPATH中新建log4j.properties配置文件,内容如下: log4j.rootLogger=DEBUG,stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layo

mysql输出信息保留++--边框方法

我这方法是通过expect实现的. 安装expect yum install -y expect 操作: [[email protected] ~]# cat test.sh /usr/local/mysql/bin/mysql -e "select version();"[[email protected] ~]# ll test.sh -rwxr-xr-x 1 root root 50 08-13 16:44 test.sh[[email protected] ~]# sh tes

退役笔记一#MySQL = lambda sql : sql + &amp;#39; Source Code 4 Explain Plan &amp;#39;

Mysql 查询运行过程 大致分为4个阶段吧: 语法分析(sql_parse.cc<词法分析, 语法分析, 语义检查 >) >>sql_resolver.cc # JOIN.prepare 生成逻辑查询plan(sql_optimizer.cc) >># JOIN.optimize 生成物理查询plan(sql_planner.cc) run the explain plan(sql_executor.cc) JOIN.exec JOIN.prepare() : 子查询