EXPLAIN
参考:
- https://blog.csdn.net/wanbin6470398/article/details/82256436
- https://blog.csdn.net/weixin_41558728/article/details/81704916
一 用例
id |
select_type |
table |
partitions |
type |
possible_keys |
key |
key_len |
ref |
rows |
filtered |
Extra |
执行顺序 |
查询类型 |
目标表 |
目标分区 |
连接使用的类型 |
可能使用的索引 |
实际选择的索引 |
使用的索引的长度 |
显示索引的哪一列被使用了 |
执行行数 |
按表条件过滤行的百分比 |
附加信息 |
1 |
SIMPLE |
t_level_type |
|
ref |
PRIMARY |
PRIMARY |
152 |
const |
2510 |
1.11 |
Using where |
1 |
SIMPLE |
t_flow_main |
|
ALL |
|
|
|
|
3309759 |
0 |
Using where; Using join buffer (Block Nested Loop) |
二 EXPLAIN 字段清单
列名 |
JSON Name |
Meaning |
id |
select_id |
查询序列号 ,或执行顺序提示信息。MySQL Query Optimizer 选定的执行计划中查询的序列号。表示查询中执行 select 子句或操作表的顺序, id 值越大优先级越高,越先被执行。 id 相同,执行顺序由上至下。 |
select_type |
None |
查询类型 |
table |
table_name |
查询目标(表),输出行所引用的表 |
partitions |
partitions |
查询目标(分区),匹配的分区 |
type |
access_type |
连接使用的类型 |
possible_keys |
possible_keys |
指出 MySQL 能在该表中使用哪些索引有助于查询。如果为空,说明没有可用的索引 |
key |
key |
实际选择的索引 |
key_len |
key_length |
使用的索引的长度。在不损失精确性的情况下,长度越短越好 |
ref |
ref |
显示索引的哪一列被使用了 |
rows |
rows |
MYSQL 认为必须检查的用来返回请求数据的行数 |
filtered |
filtered |
按表条件过滤行的百分比 |
Extra |
None |
附加信息 |
三 查询顺序,【id字段】
查询序列号 , MySQL Query Optimizer 选定的执行计划中查询的序列号。表示SQL执行顺序.
一看数值、二看顺序。id值本质是执行的分组标识,数值大的分组先被执行,id值相同表示在同一分组,执行顺序从上到下。
3.1 id值不同:数值大的先被执行。
如果是子查询,id的序号会递增
3.2 id值相同:执行顺序由上至下
3.3 id值相同又不同:
id如果相同,可以认为是一组,从上往下顺序执行;在所有组中,id值越大,优先级越高,越先执行
四 查询目标,【table】【partitions】
- table , 目标表,可以是一张明确的表,也可以是一张经过排序的临时表()。
- partitions, 目标分区
五 select_type,查询类型标识
怎么做查的,怎么做事的。
select_type Value |
JSON Name |
Meaning |
SIMPLE |
None |
简单的SELECT(不使用UNION或子查询) |
PRIMARY |
None |
最外层的SELECT |
UNION |
|
None |
DEPENDENT UNION |
dependent (true) |
UNION中的第二个或随后的SELECT语句,依赖于外部查询 |
UNION RESULT |
union_result |
UNION 查询的结果集 |
SUBQUERY |
None |
子查询中的第一个SELECT查询,不依赖于外部查询的结果集 |
DEPENDENT SUBQUERY |
dependent (true) |
子查询中的第一个SELECT,依赖于外部查询的结果集 |
DERIVED |
None |
用于 from 子句里有子查询的情况。 MySQL会递归执行这些子查询,把结果放在临时表里 |
MATERIALIZED materialized_from_subquery 物化子查询
UNCACHEABLE SUBQUERY cacheable (false) 结果集不能被缓存的子查询,必须重新为外层查询的每一行进行评估
UNCACHEABLE UNION cacheable (false) UNION 中的第二个或随后的 select 查询,属于不可缓存的子查询
六 type
性能:
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
type |
说明 |
ALL |
全数据表扫描 |
index |
全索引表扫描 |
RANGE |
对索引列进行范围查找 |
INDEX_MERGE |
合并索引,使用多个单列索引搜索 |
REF |
根据索引查找一个或多个值 |
EQ_REF |
搜索时使用primary key 或 unique类型 |
CONST |
常量,表最多有一个匹配行,因为仅有一行,在这行的列值可被优化器剩余部分认为是常数,const表很快,因为它们只读取一次。 |
SYSTEM |
系统,表仅有一行(=系统表)。这是const联接类型的一个特例。 |
七 索引, possible_keys & key & ref
- possible_keys ,可能会用到的索引 , null值表示没用到
- key , 实际使用的索引
- ref , 引用了,其他表的索引
场景一 、【可能会】有索引,【实际情况】走索引。
最佳,理想情况。
possible_keys |
key |
index_id |
index_id |
场景二、 【可能会】有索引,【实际情况】没走索引。
where 子句中有索引, select 子句使用 *
possible_keys |
key |
index_id |
|
场景三、 【可能会】为空,【实际情况】走索引。
where 子句中没有使用索引,select 子句有索引所以实际被使用
possible_keys |
key |
null |
index_id |
八 索引长度 key_len
越短越好
九 rows ,filtered
- rows ,估算找到记录需要读取的函数(根据表统计信息)
- 没建索引肯定是全表走,建了索引肯定走一部分。(数据结构)
- filtered , 满足查询的记录数量的比例(值越打越好)
十 Extra , 扩展信息
- Using filesort , 使用了文件排序,
- Using temporay , 临时表
- Using index, 使用了索引
- Using where , 使用了where 条件
- Using join bufffer , 使用了缓存
- impossible where , where 子句值总是false 不能用来获取任何元组。
-