MySQL的执行计划详解(Explain)

这篇具有很好参考价值的文章主要介绍了MySQL的执行计划详解(Explain)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1、MySQL执行计划的定义

在 MySQL 中可以通过 explain 关键字模拟优化器执行 SQL语句,从而知道 MySQL 是如何处理 SQL 语句的。

2、MySQL整个查询的过程

• 客户端向 MySQL 服务器发送一条查询请求
• 服务器首先检查查询缓存,如果命中缓存,则立刻返回存储在缓存中的结果。否则进入下一阶段
• 服务器进行 SQL 解析、预处理、再由优化器生成对应的执行计划
• MySQL 根据执行计划,调用存储引擎的 API 来执行查询
• 将结果返回给客户端,同时缓存查询结果
注意:只有在8.0之前才有查询缓存,8.0之后查询缓存被去掉了

3、如何启动执行计划

explain select 投影列 FROM 表名 WHERE 条件 ;

4、explain中的列

MySQL的执行计划详解(Explain)

4.1、id

查询执行顺序:
id 值相同时表示从上向下执行
id 值相同被视为一组
如果是子查询,id 值会递增,id 值越高,优先级越高
id为NULL最后执行。

4.2、select_type

● simple:表示查询中不包含子查询或者 union
EXPLAIN select * from actor where id=1;
MySQL的执行计划详解(Explain)
● primary:当查询中包含任何复杂的子部分,最外层的查询被标记成 primary
● derived:在 from 的列表中包含的子查询被标记成 derived
● subquery:在 select 或 where 列表中包含了子查询,则子查询被标记成 subquery
用个例子来了解primary、subquery和derived
set session optimizer_switch=‘derived_merge=off’;#关闭mysql5.7新特性对衍生表的合并优化
explain select (select 1 from actor where id = 1) from (select * from film where id = 1) der;
MySQL的执行计划详解(Explain)
set session optimizer_switch=‘derived_merge=on’; #还原默认配置
● union:两个 select 查询时前一个标记为 PRIMARY,后一个标记为 UNION。union 出现在 from 从句子查询中,外层 select 标记为 PIRMARY,union 中第一个查询为 DERIVED,第二个子查询标记为 UNION
explain select 1 union all select 1;
MySQL的执行计划详解(Explain)
● unionresult:从 union 表获取结果的 select 被标记成 union result 。

4.3、table

显示这一行的数据是关于哪张表的。
当 from 子句中有子查询时,table列是 格式,表示当前查询依赖 id=N 的查询,于是先执行 id=N 的查询。
当有 union 时,UNION RESULT 的 table 列的值为<union1,2>,1和2表示参与 union 的 select 行id。

4.4、type

这是重要的列,显示连接使用了何种类型。
SQL 性能优化的目标:至少要达到 range 级别,要求是 ref 级别,如果可以是 consts 最好。
说明:
1) consts 单表中最多只有一个匹配行(主键或者唯一索引),在优化阶段即可读取到数据。
2) ref 指的是使用普通的索引(normal index)。
3) range 对索引进行范围检索。
反例:explain 表的结果,type=index,索引物理文件全扫描,速度非常慢,这个 index 级别比较 range
还低,与全表扫描是小巫见大巫。

从最好到最差的连接类型为 system > const > eq_reg > ref > range > index > ALL
一般来说,得保证查询达到range级别,最好达到ref
● NULL:mysql能够在优化阶段分解查询语句,在执行阶段用不着再访问表或索引。例如:在索引列中选取最小值,可以单独查找索引来完成,不需要在执行时访问表
explain select min(id) from film;
MySQL的执行计划详解(Explain)
● system:表中只有一行数据。属于 const 的特例。如果物理表中就一行数据为 ALL
● const :查询结果最多有一个匹配行。因为只有一行,所以可以被视为常量。const 查询速度非常快,因为只读一次。一般情况下把主键或唯一索引作为唯一条件的查询都是 const
explain select * from (select * from film where id = 1) tmp;
MySQL的执行计划详解(Explain)
● eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见于主键或唯一索引扫描。
explain select * from film_actor left join film on film_actor.film_id = film.id
MySQL的执行计划详解(Explain)
● ref:非唯一性索引扫描,返回匹配某个单独值得所有行。索引要和某个值相比较,可能会找到多个符合条件的行。

1.简单 select 查询,name是普通索引(非唯一索引)
explain select * from film where name = ‘film1’;
MySQL的执行计划详解(Explain)
2.关联表查询,idx_film_actor_id是film_id和actor_id的联合索引,这里使用到了film_actor的左边前缀film_id部分
explain select film_id from film left join film_actor on film.id = film_actor.film_id;
MySQL的执行计划详解(Explain)
● range:把这个列当作条件只检索其中一个范围。常见 where 从句中出现 between、<、>、>=、in 等。主要应用在具有索引的列中
explain select * from actor where id > 1;
MySQL的执行计划详解(Explain)
● index:full index scan全索引扫描,index与all的区别为:index类型只遍历索引树,这通常比all快,因为索引文件通常比数据文件小。也就是说虽然index和all都是读全表,但index是从索引中读的,而all是从硬盘中读的。
explain select * from film;
MySQL的执行计划详解(Explain)
● ALL:即全表扫描,扫描你的聚簇索引的所有叶子节点。通常情况下这需要增加索引来进行优化了。
explain select * from actor;
MySQL的执行计划详解(Explain)

4.5、possible_keys (可能用到的索引)

  1. 查询条件字段涉及到的索引,可能没有使用。
  2. explain 时可能出现 possible_keys 有列,而 key 显示 NULL 的情况,这种情况是因为表中数据不多,mysql认为索引对此查询帮助不大,选择了全表查询。
  3. 如果该列是NULL,则没有相关的索引。在这种情况下,可以通过检查 where 子句看是否可以创造一个适当的索引来提高查询性能,然后用 explain 查看效果

4.6、key (实际使用的索引)

实际使用的索引。如果为 NULL,则没有使用索引。
如果想强制mysql使用或忽视possible_keys列中的索引,在查询中使用 forceindex、ignore index。

4.7、key_len (索引的长度)

表示索引中使用的字节数,查询中使用的索引的长度(最大可能长度),并非实际使用长度,理论上长度越短越好。key_len 是根据表定义计算而得的,不是通过表内检索出的。
例子:
film_actor的联合索引 idx_film_actor_id 由 film_id 和 actor_id 两个int列组成,并且每个int是4字节。通过结果中的key_len=4可推断出查询使用了第一个列:film_id列来执行索引查找。
explain select * from film_actor where film_id = 2;
MySQL的执行计划详解(Explain)
MySQL的执行计划详解(Explain)

4.8、ref

显示索引的哪一列被使用了,如果可能的话,是一个常量 const。

4.9、rows

根据表统计信息及索引选用情况,大致估算出找到所需的记录所需要读取的行数。注意这个不是结果集里的行数, 数值越低越好。

4.10、fitered

显示了通过条件过滤出的行数的百分比估计值。

4.11、Extra (额外的)

MYSQL 如何解析查询的额外信息。

  1. Distinct: MySQL 发现第 1 个匹配行后,停止为当前的行组合搜索更多的行。

  2. Not exists:MySQL 能够对查询进行 LEFT JOIN 优化,发现 1 个匹配 LEFT JOIN 标准的行后,不再为前面的的行组合在该表内检查更多的行。

  3. range checked for each record (index map: #):MySQL 没有发现好的可以使用的索引,但发现如果来自前面的表的列值已知,可能部分索引可以使用。

  4. Using filesort: 说明mysql会对数据使用**一个外部的索引排序,而不是按照表内的索引顺序进行读取。Mysql中无法利用索引完成的排序操作称为“文件排序”**这种情况下一般也是要考虑使用索引来优化的。
    4.1. actor.name未创建索引,会浏览actor整个表,保存排序关键字name和对应的id,然后排序name并检索行记录
    explain select * from actor order by name;
    MySQL的执行计划详解(Explain)
    4.2. film.name建立了idx_name索引,此时查询时extra是using index
    explain select * from film order by name;
    MySQL的执行计划详解(Explain)

  5. Using index: 表示相应的select操作中使用了覆盖索引,避免访问了表的数据行,效率不错!
    如果同时出现了using where,表明索引被用来执行索引键值的查找;
    如果没有同时出现using where,表明索引用来读取数据而非执行查找动作
    explain select film_id from film_actor where film_id = 1;
    MySQL的执行计划详解(Explain)

  6. Using temporary:为了解决查询,MySQL 需要创建一个临时表来容纳结果。使用了临时表保存中间结果。常见于排序order by和分组查询group by。
    Using filesort和Using temporary都是不太好的结果,会影响性能。
    6.1. actor.name没有索引,此时创建了张临时表来distinct
    explain select distinct name from actor;
    MySQL的执行计划详解(Explain)
    6.2. film.name建立了idx_name索引,此时查询时extra是using index,没有用临时表
    explain select distinct name from film;
    MySQL的执行计划详解(Explain)

  7. Using where: 表示使用了where过滤。
    explain select * from actor where name = ‘a’;

  8. Using sort_union(…), Using union(…), Using intersect(…): 这 些 函 数 说 明 如 何 为index_merge 联接类型合并索引扫描。

  9. Using index for group-by:类似于访问表的 Using index 方式,Using index for group-by 表示MySQL发现了一个索引,可以用来查 询GROUP BY或DISTINCT查询的所有列,而不要额外搜索硬盘访问实际的表。文章来源地址https://www.toymoban.com/news/detail-426285.html

到了这里,关于MySQL的执行计划详解(Explain)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【MySQL数据库 | 第二十篇】explain执行计划

    目录  前言: explain:  语法: 总结:         上一篇我们介绍了从时间角度分析MySQL语句执行效率的三大工具:SQL执行频率,慢日志查询,profile。但是这三个方法也只是在时间角度粗略的查看SQL语句效率,我们要想看一个语句的真正性能,还要借助explain来查看SQL语句的优

    2024年02月11日
    浏览(48)
  • 一文带你了解MySQL之Explain执行计划

    前言: 一条查询语句在经过MySQL查询优化器的各种基于成本和规则的优化会后生成一个所谓的 执行计划 ,这个执行计划展示了接下来具体执行查询的方式,比如多表连接的顺序是什么,对于每个表采用什么访问方法来具体执行查询等等。 MySQL 为我们提供了 EXPLAIN 语句来帮助

    2024年02月06日
    浏览(43)
  • 玩转MySQL之SQL优化之EXPLAIN执行计划

    从今天开始本系列文章就带各位小伙伴学习数据库技术。 数据库技术是Java开发中必不可少的一部分知识内容。也是非常重要的技术。本系列教程由浅入深, 全面讲解数据库体系。 非常适合零基础的小伙伴来学习。 全文大约 【1965】字 ,不说废话,只讲可以让你学到技术、明

    2024年02月08日
    浏览(56)
  • Mongo执行计划explain分析

    3.0+的explain有三种模式,分别是:queryPlanner、executionStats、allPlansExecution。现实开发中,常用的是 executionStats模式 。 在查询语句后面加上explain(\\\"executionStats\\\")   第一层:executionTimeMillis  最为直观explain返回值是 executionTimeMillis值 ,指的是我们 这条语句的执行时间 ,这个值当然

    2024年02月04日
    浏览(59)
  • HiveSQL执行计划查看(EXPLAIN)

    Hive是一个基于Hadoop的数据仓库工具,通过SQL语言对分布式数据进行处理。在Hive中,执行计划是指查询语句的执行过程,包括查询语句的优化、查询计划生成和查询执行。对于HiveSQL的执行计划可以通过EXPLAIN命令进行查看。本文将为大家介绍HiveSQL执行计划的相关内容。 EXPLAI

    2024年02月16日
    浏览(35)
  • Spark Explain:查看执行计划

    Spark SQL explain 方法有 simple、extended、codegen、cost、formatted 参数,具体如下 从 3.0 开始,explain 方法有一个新的 mode 参数,指定执行计划展示格式 只展示物理执行计划,默认 mode 是 simple spark.sql(sqlstr).explain() 展示物理执行计划和逻辑执行计划 spark.sql(sqlstr).explain(mode=“extended”

    2024年02月16日
    浏览(45)
  • SQL优化之EXPLAIN执行计划

    从今天开始本系列文章就带各位小伙伴学习数据库技术。 数据库技术是Java开发中必不可少的一部分知识内容。也是非常重要的技术。本系列教程由浅入深, 全面讲解数据库体系。 非常适合零基础的小伙伴来学习。 全文大约 【1965】字 ,不说废话,只讲可以让你学到技术、明

    2024年02月07日
    浏览(77)
  • ClickHouse查看执行计划(EXPLAIN语法)

    EXPLAIN [AST | SYNTAX | QUERY TREE | PLAN | PIPELINE | ESTIMATE | TABLE OVERRIDE] [setting = value, ...]     [       SELECT ... |       tableFunction(...) [COLUMNS (...)] [ORDER BY ...] [PARTITION BY ...] [PRIMARY KEY] [SAMPLE BY ...] [TTL ...]     ]     [FORMAT ...] 查询计划的类型说明:  AST(抽象语法树):在AST级别优化之后的查

    2024年02月13日
    浏览(38)
  • MySQL 执行计划详解

    本文基于MySQL 8.0编写,理论支持MySQL 5.0及更高版本。 id :该语句的唯一标识。如果explain的结果包括多个id值,则数字越大越先执行;而对于相同id的行,则表示从上往下依次执行。 select_type :查询类型,有如下几种取值: table :表示当前这一行正在访问哪张表,如果SQL定义

    2024年02月13日
    浏览(43)
  • 利用auto_explain查看sql、procedure、function实时执行计划

    postgresql中,利用explain 结合一些选项,如analyze、buffers等命令查看sql语句执行计划在一般场景下已经足够,但是基于如下原因,auto_explain将是一个强有力的补充: 鉴于pg优化器的复杂性,以及柱状图不同值数据的分布,sql不总是按照我们使用explain工具看到的执行计划执行 对于

    2024年02月12日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包