『Mysql』在Mysql中的执行计划超详细分析

『Mysql』在Mysql中的执行计划超详细分析_mysql执行计划类型_老陈聊架构的博客-CSDN博客

文章目录
一、概念篇
1 什么是Explain
2 为什么要使用Explain
二、Explain分析
1. 先执行Sql,然后通过Explain分析
2.然后分析语句详细细节
3.执行计划-ID
4.执行计划-select-type
5.执行计划-type
6.执行计划-possible_keys
7.执行计划-key_len
8.执行计划-ref
9.执行计划-rows
10.执行计划-Extra

看这篇文章前需要先了解一下以下几个小问题~

一、概念篇
1 什么是Explain
分析sql语句执行计划。
2 为什么要使用Explain
了解sql语句如何从表中查询到目标数据

二、Explain分析
1. 先执行Sql,然后通过Explain分析
举例

EXPLAIN
SELECT * FROM `Seckills` AS `s`

2.然后分析语句详细细节

id: 查询的唯一标识
select_type: 查询的类型
table: 查询的表, 可能是数据库中的表/视图，也可能是 FROM 中的子查询
type: 搜索数据的方法
possible_keys: 可能使用的索引
key: 最终决定要使用的key
key_len: 查询索引使用的字节数。通常越少越好
ref: 查询的列或常量
rows: 需要扫描的行数，估计值。通常越少越好
extra: 额外的信息
3.执行计划-ID
select查询的序列号,包含一组数字，表示查询中执行select子句或操作表的顺序

有三种情况：
（1）id相同，执行顺序由上至下
（2）id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
（3）id有相同也有不同，同时存在

4.执行计划-select-type
SIMPLE: 简单查询，不包含子查询和union
PRIMRARY: 包含子查询时的最外层查询; 使用union时的第一个查询
UNION: 包含union的查询中非第一个查询
UNION RESULT 临时结果
DEPENDENT UNION: 与 UNION 相同，但依赖外层查询的结果
SUBQUERY: 子查询
DEPENDENT SUBQUERY: 依赖外层查询的子查询
DERIVED: 用于 FROM 中的子查询(中间表)
举例：
example1:联合查询

SELECT `a`.`ProductId` FROM `Seckills` AS `a` 
  union
SELECT `b`.`ProductId` FROM `Seckills` AS  `b` 
 union
SELECT `c`.`ProductId` FROM `Seckills` AS  `c

example2:子查询

SELECT * FROM Seckills WHERE SeckillId = 
(SELECT SeckillId FROM seckillrecords WHERE SeckillNum = 1);

example3:子查询依赖查询

SELECT * FROM Seckills WHERE SeckillId = 
(SELECT SeckillId FROM seckillrecords WHERE SeckillNum = 1 and Seckills.SeckillId = seckillrecords.SeckillId);

5.执行计划-type
type 字段描述了查询的方式，从好到坏为:

null: 不需要访问索引和表即可完成
示例:

SELECT 1;

const: 表中仅有一行匹配，在分解查询计划时直接将其读出作为常量使用。system 是 const 类型的特例，通过直接匹配主键或者唯一约束的字段。
示例:

SELECT * FROM Seckills WHERE SeckillId = 4;

id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    SIMPLE    user    const    uni_name    uni_name    258    const    1    Using index
eq_ref: 使用 PRIMARY KEY 或 UNIQUE KEY 进行关联查询。
示例:

   SLECT *
FROM Seckills INNER JOIN seckillrecords 
ON Seckills .SeckillId = seckillrecords .SeckillId 
WHERE seckillrecords .SeckillNum = 1

id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    SIMPLE    Seckills    ALL    idx_uid    0    0    0    57796    null
1    SIMPLE    seckillrecords    eq_ref    PRIMARY    PRIMARY    8    post.uid    1    Using where
ref: 使用允许重复的索引进行查询
示例:

SELECT * FROM seckillrecords WHERE SeckillNum=1;

id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    SIMPLE    user    ref    SeckillNum    SeckillNum    4    const    1    Using index condition
range: 使用索引进行范围查询:
示例:

SELECT * FROM seckillrecords WHERE age > 2;

id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    SIMPLE    user    range    idx_age    idx_age    259    const    1    null
index: 在索引上进行顺序扫描。常见于在多列索引中未使用最左列进行查询。
示例:

SELECT * FROM seckillrecords WHERE OrderSn  = 'sminit';

id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    SIMPLE    user    index    idx_full_name_osn    idx_full_name_osn    259    const    1    Using where
all: 扫描全表，最坏的情况

6.执行计划-possible_keys
实际使用的索引。
如果为NULL，则没有使用索引，查询中若使用了覆盖索引，则该索引和查询的select字段重叠

7.执行计划-key_len
索引使用的字节数，相当于长度

char和varchar跟字符编码也有密切的联系,
​ latin1占用1个字节，gbk占用2个字节，utf8占用3个字节。（不同字符编码占用的存储空间不同）

8.执行计划-ref
显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值

9.执行计划-rows
根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数

10.执行计划-Extra
extra 列显示了查询过程中需要执行的其它操作，有些情况应尽力避免。

using filesort: 查询时执行了排序操作而无法使用索引排序。虽然名称为’file’但操作可能是在内存中执行的，取决是否有足够的内存进行排序。
应尽量避免这种filesort出现。
using temporary: 使用临时表存储中间结果，常见于ORDER BY和GROUP BY语句中。临时表可能在内存中也可能在硬盘中，应尽量避免这种操作出现。
using index: 索引中包含查询的所有列不需要查询数据表(回表)。可以加快查询速度。
using where: 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给客户端
using index condition: 索引条件推送(MySQL 5.6 新特性)，服务器层将不能直接使用索引的查询条件推送给存储引擎，从而避免在服务器层进行过滤。
distinct: 优化distinct操作，查询到匹配的数据后停止继续搜索
————————————————
版权声明：本文为CSDN博主「老陈聊架构」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_34202873/article/details/121064539