长达 1.7 万字的 explain 关键字指南!

news2024/11/23 16:58:33

当你的数据里只有几千几万,那么 SQL 优化并不会发挥太大价值,但当你的数据里去到了几百上千万,SQL 优化的价值就体现出来了!因此稍微有些经验的同学都知道,怎么让 MySQL 查询语句又快又好是一件很重要的事情。要让 SQL 又快又好的前提是,我们知道它「病」在哪里,而 explain 关键字就是 MySQL 提供给我们的一把武器!

在我们所执行的 SQL 前面加上 explain 关键字,MySQL 就不会真正去执行这条语句,而是模拟优化器执行 SQL 查询语句,最后会输出一系列的指标告诉我们这条语句的性能如何,如下图所示。

mysql> explain select * from student where id = 1 \G
******************************************************
           id: 1
  select_type: SIMPLE
        table: subject
   partitions: NULL
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
     filtered: 100.00
        Extra: NULL
******************************************************

总的来说,explain 关键字可以告诉我们下面这么多信息:

  1. 表的读取顺序如何

  2. 数据读取操作有哪些操作类型

  3. 哪些索引可以使用

  4. 哪些索引被实际使用

  5. 表之间是如何引用

  6. 每张表有多少行被优化器查询

......

今天,我们就来介绍 explain 关键字的各个指标的含义。系好安全带,准备发车了!

为了方便讲解,这里新建了几张表,并初始化了一些数据(建表语句见附录)。这些表的关系如下:

  • 一共有老师、学生、课程三个实体,分别为:teacher、student、course。

  • 三个实体间的关系分别为:老师教学生的关系(teacher_student)、学生的课程分数(student_course)。

ID 字段

ID 字段的值及其排列顺序,表明 MySQL 执行时从各表取数据的顺序。一般情况下遵循下面两个原则:

  • ID 相同的组,其执行优先级按照其顺序由上到下。

  • ID 越大的组,其执行优先级越高。

对于下面这个例子:

EXPLAIN SELECT
	teacher.* 
FROM
	teacher,
	teacher_student 
WHERE
	teacher_student.student_name = 's001' 
	AND teacher.NAME = teacher_student.teacher_name

该例子的输出为:

上面的输出一共有 2 条记录,其 ID 都为 1,这表示其归为一组。对于 ID 相同的组,MySQL 按照顺序从上到下执行,即:先拿 teacher_student 表的数据,再拿 teacher 表的数据。

再来看下面这个例子:

EXPLAIN SELECT
	* 
FROM
	teacher 
WHERE
	NAME IN ( SELECT teacher_name FROM teacher_student WHERE student_name = 'S002' )

该例子的输出为:

上面的输出一共有 3 条记录,其中第 1、2 条的 ID 相同,第 3 条 ID 不同。那么其执行顺序就是 ID 值越大,其越早执行。ID 相同的,按顺序执行。上面的例子,最早拿 teacher_student 表的数据,之后是一个子查询组成的表,最后拿 teacher 表的数据。结合 SQL 分析,这也符合我们的常识。因为我们必须先把子查询的值算出来,因此需要先把 teacher_student 表里的数据拿出来,之后才可以拿去 teacher 表里查询。

select_type 字段

select_type 字段表示该 SQL 是什么查询类型,一共有以下 6 种:

  • SIMPLE:简单查询,不包含子查询或 union 查询

  • PRIMARY:主键查询

  • SUBQUERY:在 select 或 where 中包含子查询

  • DERIVED:from 中包含子查询

  • UNION:

  • UNION RESULT

SIMPLE

简单查询,不包含子查询或 union 查询。

-- 查询T001老师都教了哪些学生
EXPLAIN SELECT
	student.* 
FROM
	teacher,
	teacher_student,
	student 
WHERE
	teacher.NAME = 'T001' 
	AND teacher.NAME = teacher_student.teacher_name 
	AND teacher_student.student_name = student.NAME

可以看出其 3 个查询都是简单(SIMPLE)查询。因为 ID 相同,所以其查询顺序是按顺序来的。首先从 teacher 表中取出数据,之后从 student 表取出数据,最后 teacher_student 表取数据。

PRIMARY

一般情况下,如果查询中包含了任何复杂的子查询,那么最外层查询会被标记为主查询。

-- PRIMARY 查询哪些老师教授了选修数学课的学生
EXPLAIN SELECT
	* 
FROM
	teacher 
WHERE
	NAME IN ( SELECT teacher_name FROM teacher_student WHERE student_name = ( SELECT student_name FROM student_course WHERE course_name = 'shuxue' ) )

在上面的查询中,首先是执行 ID 为 3 的查询,即去 student_course 表取出选修了数学课的学生名字,之后再去进行最外层的查询。可以看到最外层查询的 select_type 为 PRIMARY。

SUBQUERY

在 select 或 where 中包含子查询,那么 select_type 会被标记为 SUBQUERY。以上面的查询为例:

-- PRIMARY 查询哪些老师教授了选修数学课的学生
EXPLAIN SELECT
	* 
FROM
	teacher 
WHERE
	NAME IN ( SELECT teacher_name FROM teacher_student WHERE student_name = ( SELECT student_name FROM student_course WHERE course_name = 'shuxue' ) )

在该查询中,where 中包含了子查询,因此在 explain 中有一个 ID 为 3 的查询被标记为 SUBQUERY。

DERIVED

在 FROM 中包含子查询,那么 select_type 会被标记为 SUBQUERY。

UNION

类似包含 union 关键字的会被标记成 UNION 类型,这种查询方式比较少,这里不做深入讲解。

UNION RESULT

类似包含 union 关键字的会被标记成 UNION RESULT 类型,这种查询方式比较少,这里不做深入讲解。

type 字段

type 字段表示访问情况,通常用来衡量 SQL 的查询效率。其值的查询效率从最好到最差分别为:

  • NULL

  • system

  • const

  • eq_ref

  • ref

  • fulltext

  • ref_or_null

  • index_merge

  • unique_subquery

  • index_subquery

  • range

  • index

  • ALL

NULL

NULL 表示 MySQL 能够在优化阶段分解查询语句,在执行阶段用不着再访问表或索引。

explain select max(id) from teacher

system

表只有一行记录(等于系统表),这是const类型的特列。

出现的情况较少,这里不深入介绍。

const

const 表示该表最多有一个匹配记录。

通常情况下是 SQL 中出现了主键索引或唯一索引。

explain select * from teacher where name = 'T002'

上面例子中,teacher.name 字段为唯一索引字段,所以通过该字段只能唯一找到一条记录,因此其 type 类型为 const。

eq_ref

eq_ref 表示主键索引或唯一索引的所有部分被连接使用 ,最多只会返回一条符合条件的记录。

与 const 类型非常相似,唯一的区别是 eq_ef 通常出现在联表的情况下,而 const 通常出现在单表情况下。

EXPLAIN SELECT
	* 
FROM
	teacher,
	teacher_student 
WHERE
	teacher.NAME = teacher_student.teacher_name

从上面的执行结果可以看出,其首先全表扫描了 teacher_student 表,之后使用 teacher.name 唯一索引去将联合 teacher 表的每一条记录。

要注意的是,eq_ref 这种情况重点在于:读取本表中和关联表表中的每行组合成的一行。 如果并没有关联表中每行这个概念,那么就不会出现 eq_ref 这种类型。例如我在上面的 SQL 中加上 age 为 24 这个条件,即 SQL 为:

EXPLAIN SELECT
	* 
FROM
	teacher,
	teacher_student 
WHERE
	teacher.NAME = teacher_student.teacher_name and teacher.age = 24

执行计划变为:

会看到 type 类型都变为 ref 了,eq_ref 消失了。

ref

ref 表示使用了非唯一索引扫描,会返回匹配某个单独值的所有行。

与 const 非常类似,只不过 ref 会匹配到多个记录,而 const 则只会匹配到单个记录。

explain select * from teacher where age = 24

age 为普通索引,表中有 2 条记录。

表中数据为:

ref_or_null

类似ref,但是可以搜索值为NULL的行。

explain select * from teacher where age = 24 or age is null

当我们增加 age is null 查询条件后,其 type 字段就变成了 ref_or_null

index_merge

表示使用了索引合并的优化方法。

索引合并指的是:对多个索引分别进行条件扫描,然后将它们各自的结果进行合并。

EXPLAIN SELECT * from teacher where id = 1 or age = 24

执行计划为:

可以看到使用了 index_merge 的查询类型。在 teacher 表中 id 和 age 都是索引,其将两个字段的索引结果进行合并了。

range

range 表示检索给定范围的行,使用一个索引来选择行,key 列显示使用了哪个索引。

一般就是在你的 where 语句中出现 between、<>、in 等的范围查询。

执行计划为:

上面语句中,我们使用 between 进行范围查询,因此 type 类型为 range。

index

index 表示只遍历索引树,且只从索引树中获取数据。

EXPLAIN SELECT id, age FROM TEACHER 

上面 SQL 中的 id、age 都是索引字段,可以直接从索引树中读取。因此其 type 字段为 index,表示此次查询数据可以直接从索引树获取到。但是如果查询的字段不在索引树中,那么就是全表扫描了。例如:

EXPLAIN SELECT id, enter_time FROM TEACHER 

查询 SQL 的 enter_time 字段不是索引,所以上面的查询就变成了全表查询(ALL)。

ALL

ALL 表示该查询将遍历全表以找到匹配行,这是最糟糕的一种查询方式。

table 字段

表示数据来自哪张表

possible_keys 字段

显示可能应用在这张表中的索引,一个或多个。

查询涉及到的字段若存在索引,则该索引将被列出,但不一定被实际使用。

key 字段

实际使用到的索引,如果为NULL,则没有使用索引。

查询中若使用了覆盖索引(查询的列刚好是索引),则该索引仅出现在key列表。

mysql> explain select * from film_actor where film_id = 2;
+----+-------------+------------+------+-------------------+-------------------+---------+-------+------+-------------+
| id | select_type | table      | type | possible_keys     | key               | key_len | ref   | rows | Extra       |
+----+-------------+------------+------+-------------------+-------------------+---------+-------+------+-------------+
|  1 | SIMPLE      | film_actor | ref  | idx_film_actor_id | idx_film_actor_id | 4       | const |    1 | Using index |
+----+-------------+------------+------+-------------------+-------------------+---------+-------+------+-------------+

key_len计算规则如下:

字符串

  • char(n):n字节长度

  • varchar(n):2字节存储字符串长度,如果是utf-8,则长度 3n + 2

数值类型

  • tinyint:1字节

  • smallint:2字节

  • int:4字节

  • bigint:8字节 

时间类型

  • date:3字节

  • timestamp:4字节

  • datetime:8字节

其他

如果字段允许为 NULL,需要1字节记录是否为 NULL

ref 字段

这一列显示了在 key 列记录的索引中,表查找值所用到的列或常量,常见的有:const(常量),func,NULL,字段名(例:film.id)。

rows 列

这一列是mysql估计要读取并检测的行数,注意这个不是结果集里的行数。

Extra 列

这一列展示的是额外信息。

distinct

一旦mysql找到了与行相联合匹配的行,就不再搜索了。

mysql> explain select distinct name from film left join film_actor on film.id = film_actor.film_id;
+----+-------------+------------+-------+-------------------+-------------------+---------+--------------+------+------------------------------+
| id | select_type | table      | type  | possible_keys     | key               | key_len | ref          | rows | Extra                        |
+----+-------------+------------+-------+-------------------+-------------------+---------+--------------+------+------------------------------+
|  1 | SIMPLE      | film       | index | idx_name          | idx_name          | 33      | NULL         |    3 | Using index; Using temporary |
|  1 | SIMPLE      | film_actor | ref   | idx_film_actor_id | idx_film_actor_id | 4       | test.film.id |    1 | Using index; Distinct        |
+----+-------------+------------+-------+-------------------+-------------------+---------+--------------+------+------------------------------+

Using index

这表示查找某个表的时候,所需要的信息直接从索引就可以拿到,而不需要再访问行记录。

mysql> explain select id from film order by id;
+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | film  | index | NULL          | PRIMARY | 4       | NULL |    3 | Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+ 

上面例子中,我只是选择了 id 列,这个列本身是索引,其信息直接在索引树中就可以拿到,因此不需要再访问行记录。

Using where

mysql 服务器将在存储引擎检索行后再进行过滤。就是先读取整行数据,再按 where 条件进行检查,符合就留下,不符合就丢弃。

mysql> explain select * from film where id > 1;
+----+-------------+-------+-------+---------------+----------+---------+------+------+--------------------------+
| id | select_type | table | type  | possible_keys | key      | key_len | ref  | rows | Extra                    |
+----+-------------+-------+-------+---------------+----------+---------+------+------+--------------------------+
|  1 | SIMPLE      | film  | index | PRIMARY       | idx_name | 33      | NULL |    3 | Using where; Using index |
+----+-------------+-------+-------+---------------+----------+---------+------+------+--------------------------+

Using temporary

mysql需要创建一张临时表来处理查询。出现这种情况一般是要进行优化的,首先是想到用索引来优化。

1. actor.name没有索引,此时创建了张临时表来distinct
mysql> explain select distinct name from actor;
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra           |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------+
|  1 | SIMPLE      | actor | ALL  | NULL          | NULL | NULL    | NULL |    2 | Using temporary |
+----+-------------+-------+------+---------------+------+---------+------+------+-----------------+

2. film.name建立了idx_name索引,此时查询时extra是using index,没有用临时表
mysql> explain select distinct name from film;
+----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key      | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+
|  1 | SIMPLE      | film  | index | idx_name      | idx_name | 33      | NULL |    3 | Using index |
+----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+

Using filesort

MySQL 中无法利用索引完成的排序操作称为「文件排序」。

在MySQL中的ORDER BY有两种排序实现方式:

  1. 利用有序索引获取有序数据

  2. 文件排序

在explain中分析查询的时候,利用有序索引获取有序数据显示 Using index ,文件排序显示 Using filesort。至于什么时候使用索引排序,什么时候使用文件排序,这个问题太过于复杂,这里不做深入介绍。

1. actor.name未创建索引,会浏览actor整个表,保存排序关键字name和对应的id,然后排序name并检索行记录
mysql> explain select * from actor order by name;
+----+-------------+-------+------+---------------+------+---------+------+------+----------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |
+----+-------------+-------+------+---------------+------+---------+------+------+----------------+
|  1 | SIMPLE      | actor | ALL  | NULL          | NULL | NULL    | NULL |    2 | Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

2. film.name建立了idx_name索引,此时查询时extra是using index
mysql> explain select * from film order by name;
+----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key      | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+
|  1 | SIMPLE      | film  | index | NULL          | idx_name | 33      | NULL |    3 | Using index |
+----+-------------+-------+-------+---------------+----------+---------+------+------+-------------+

文章转载自:陈树义

原文链接:https://www.cnblogs.com/chanshuyi/p/quick-start-of-mysql-explain.html

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/752777.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

桥梁监测是做什么的?桥梁结构监测方案

现代化大型桥梁是交通主干道的重要节点&#xff0c;对交通运输发展具有重大影响。然而&#xff0c;桥梁在长期使用过程中容易受到各种因素的影响&#xff0c;如自然灾害、车辆载荷、材料老化等&#xff0c;从而导致结构损伤和安全隐患。因此&#xff0c;对桥梁结构性能进行自动…

Vue3+Vite+Pinia+Naive后台管理系统搭建之八:构建 login.vue 登录页

前言 如果对 vue3 的语法不熟悉的&#xff0c;可以移步Vue3.0 基础入门&#xff0c;快速入门。 项目所需要的图片&#xff0c;icon图标&#xff08;推荐&#xff1a;阿里巴巴矢量图标库&#xff09;自行获取&#xff0c;命名一致就行。 1. 构建 src/components/CopyRight.vu…

猿人学第一届刷题18

1.第十八题 jsvmp - 猿人学 问题: 1.第一页请求正常能返回数据 2.第二页开始之后出现{"error": "Unexpected token/Validation failed"} 分析&#xff1a; 1.第二页开始&#xff0c;有带加密参数&#xff0c;直接重发请求无果&#xff0c;应该带了时间戳…

优化产品知识库的 SEO 技巧

在当今数字化的商业环境中&#xff0c;为产品知识库进行搜索引擎优化&#xff08;SEO&#xff09;是至关重要的。随着用户越来越倾向于通过搜索引擎获取信息&#xff0c;优化产品知识库可以帮助你的企业在竞争激烈的市场中脱颖而出。 通过改进SEO&#xff0c;你可以帮助用户找到…

locust性能测试和分布式压测

一、工具介绍 Locust是一个开源的Python性能测试工具&#xff0c;用于模拟大量并发用户访问网站、API等&#xff0c;以测试系统的性能和稳定性。它的主要特点包括&#xff1a; 1.简单易用&#xff1a;Locust基于Python编写&#xff0c;使用方便&#xff0c;学习曲线较低。 2…

数据库基本操作--------MySQL 索引

目录 一、MySQL 索引 1&#xff0e;索引的概念 2&#xff0e;索引的作用 3&#xff0e;创建索引的原则依据 4&#xff0e;索引的分类和创建 &#xff08;1&#xff09;普通索引 ●直接创建索引 &#xff08;2&#xff09;唯一索引 &#xff08;3&#xff09;主键索引 ●创…

禁止浏览器自动填充密码功能,设置自动填充背景色。

禁止浏览器自动填充密码功能&#xff0c;设置自动填充背景色 1、禁止浏览器自动填充密码功能2、设置自动填充背景色&#xff08;阴影效果&#xff09; 1、禁止浏览器自动填充密码功能 text设置autocomplete“off” password设置 autocomplete“new-password” 两个一起设置&am…

雪花算法生成分布式ID源码分析及低频场景下全是偶数的解决办法

目录 雪花算法原理介绍 雪花算法源码分析 低频场景下都是偶数的原因 解决雪花算法的偶数问题 1、切换毫秒时使用随机数 2、抖动上限值加抖动序列号 雪花算法原理介绍 雪花算法(snowflake)最早是twitter内部使用的分布式下的唯一id生成算法&#xff0c;在2014年开源&…

【iOS】消息传递与消息转发

Objective-C是一门非常动态的语言&#xff0c;以至于确定调用哪个方法被推迟到了运行时&#xff0c;而非编译时。与之相反&#xff0c;C语言使用静态绑定&#xff0c;也就是说在编译期就能决定程序运行时所应该调用的函数&#xff0c;所以在C语言中&#xff0c; 如果某个函数没…

MySQL优化 | 如何正确使用索引

文章目录 一、简介1、索引的作用和优势2、索引的基本原理和数据结构 二、常见索引类型和适用场景1、B-Tree索引及其适用场景2、哈希索引及其适用场景 三、选择合适的索引策略1、 选择合适的列作为索引2、使用复合索引和最左前缀原则3、 覆盖索引的使用技巧 四、索引的创建和维护…

IDEA项目报错随笔记录

文章目录 1. 无效的源发行版: 172. java: 无法访问org.springframework.boot.SpringApplication3. java: 程序包org.junit.jupiter.api不存在4. SpringbootTest注解爆红5. maven命令安装本地jar包报错&#xff1a;[拒绝访问]5. maven命令安装本地jar包报错&#xff1a;Unknown …

华为OD机试真题 Java 实现【矩阵元素的边界值】【2023 B卷 100分】,附详细解题思路

目录 专栏导读一、题目描述二、输入描述三、输出描述四、解题思路五、Java算法源码六、效果展示1、输入2、输出3、说明4、再输入5、再输出6、再说明 专栏导读 本专栏收录于《华为OD机试&#xff08;JAVA&#xff09;真题&#xff08;A卷B卷&#xff09;》。 刷的越多&#xff…

IOS与Android APP开发的差异性

iPhone和 Android是全球最流行的两种移动平台&#xff0c;有许多不同的开发者开发了应用程序&#xff0c;并将它们发布到市场上。虽然大多数开发者都使用了这两个平台&#xff0c;但您仍然需要了解它们的差异。 虽然 iOS和 Android两个平台都是基于 Linux&#xff0c;但它们却…

流程提效80%!从3个维度搭建高效的数字化采购体系...

采购是企业经营的一个核心环节&#xff0c;也是企业获取利润和市场资源的重要部门&#xff0c;对于企业订单交付尤为关键。特别是在装备制造行业&#xff0c;项目多、零件品类多、定制化高、订单交付周期短&#xff0c;边设计边采购边生产&#xff0c;企业采购负荷重&#xff0…

读书笔记怎么写?心理学名著《乌合之众》读书笔记!

世界上这么多人&#xff0c;看似每个人是一个独立的个体&#xff0c;但其实众生如蚁&#xff0c;彼此相互影响&#xff0c;形成了复杂而神秘的群体心态。 当我们融入群体时&#xff0c;个人的特质会被群体弱化&#xff0c;变得盲从、愚昧甚至暴力&#xff0c;这就是《乌合之众》…

IP地址:超网监控

随着组织的 IT 基础架构的扩展&#xff0c;新设备会不断添加以满足不断增长的网络需求。这就需要跨多个子网管理数百个 IP 地址&#xff0c;以确保每个新添加的设备都配置了唯一的 IP 以连接到网络。为了简化此过程&#xff0c;网络管理员依赖于网络超网的概念&#xff0c;也称…

事务隔离级别是如何实现的

事务隔离级别是如何实现的 数据库系统提供了以下 4 种事务隔离级别 读未提交&#xff1a;解决了回滚覆盖类型的更新丢失&#xff0c;但可能发生脏读现象(一个事务读取到了另一个事务修改但未提交的数据)&#xff0c;也就是可能读取到其他会话中未提交事务修改的数据。 已提交…

解决报错:FUNC glfwErrorCallback GLX: Failed to create context: GLXBadFBConfig

解决报错&#xff1a;FUNC glfwErrorCallback GLX: Failed to create context: GLXBadFBConfig 执行glxinfo | grep OpenGL命令查看系统中的OpenGL信息时&#xff0c;显示以下信息&#xff1a; 根据得到的信息可以看到 OpenGL core profile version string 为 4.5 说明显卡驱…

基于web的考研信息交流平台/考研信息分享平台的设计与实现

摘 要 随着信息化时代的到来&#xff0c;管理系统都趋向于智能化、系统化&#xff0c;考研信息交流平台也不例外&#xff0c;但目前国内的有些平台仍然都使用人工管理&#xff0c;浏览网站人数越来越多&#xff0c;同时信息量也越来越庞大&#xff0c;人工管理显然已无法应对时…

【复杂系统】拥抱复杂性(第 2 部分数据)

如何通过三个简单&#xff08;ish&#xff09;步骤将您的组织网络化……从数据开始 您的信息不想被困在一个盒子里 在本文的第一部分中&#xff0c;我们确定了工业时代将复杂性组织成漂亮、整洁的线性盒子&#xff0c;尽管这是一种高效的机器制造方式&#xff0c;但这种方法已不…