庖丁解牛，MySQL执行计划Explain的2大核心

👨‍🎓 博主介绍：
IT邦德，江湖人称jeames007，10年DBA工作经验
中国DBA联盟(ACDU)成员，目前从事DBA及程序编程
（Web\java\Python）工作，主要服务于生产制造
现拥有 Oracle 11g  OCP/OCM、
Mysql、Oceanbase（OBCA）认证
分布式TBase\TDSQL数据库、国产达梦数据库以及红帽子认证

擅长主流数据Oracle、MySQL、PG 运维开发，备份恢复，
安装迁移，性能优化、故障应急处理等。

文章目录

前言

我们经常会使用Explain去查看执行计划，今天我们就详细讨论下Explain中的“Type”和“Extra”

我们经常会使用Explain去查看执行计划，这个众所周知。
但在面试时问面试者，你用Explain主要是看什么？
对方的回答大多是“查看是否有使用到索引”，这显然不是最好的答案。

🍁 一、Explain中的“Type”

Explain中的“Type”
MySQL的官网解释为：连接类型(the join type)。它描述了找到所需数据使用的扫描方式。

最为常见的扫描方式有：
system：系统表，少量数据，往往不需要进行磁盘IO；
const：常量连接；
eq_ref：主键索引(primary key)或者非空唯一索引(unique not null)等值扫描；
ref：非主键非唯一索引等值扫描；
range：范围扫描；
index：索引树扫描；
ALL：全表扫描(full table scan)；
上面各类扫描方式由快到慢：
system > const > eq_ref > ref > range > index > ALL

🍃1.1 system

扫码类型为system，说明数据已经加载到内存里，不需要进行磁盘IO。
这类扫描是速度最快的。
但是我没有遇到过，遇到了我再来补充！

🍃1.2 const

explain select id from account_user_base where id =1;
const扫描的条件为：
（1）命中主键(primary key)或者唯一(unique)索引；
（2）被连接的部分是一个常量(const)值；

🍃1.3 eq_ref

eq_ref扫描的条件为：对于前表的每一行(row)，后表只有一行被扫描。
我也没有遇到！非常少见

🍃1.4 ref

explain select * from account_user_base t1,account_user_security t2 where t1.id = t2.user_id;
对于前表的每一行(row)，后表可能有多于一行的数据被扫描。

🍃1.5 range

explain select * from account_user_base where id > 4;
range类型，它是索引上的范围查询，它会在索引上扫码特定范围内的值。

🍃1.6 index

explain select id from account_user_base;
index类型，需要扫描索引上的全部数据。

🍃1.7 ALL

explain select * from account_user_base;
全表扫描

🍃1.8总结

system最快：不进行磁盘IO
const：PK或者unique上的等值查询
eq_ref：PK或者unique上的join查询，等值匹配，对于前表的每一行(row)，后表只有一行命中
ref：非唯一索引，等值匹配，可能有多行命中
range：索引上的范围扫描，例如：between/in/>
index：索引上的全集扫描
ALL最慢：全表扫描(full table scan)

🍁二、Explain中的“Extra”

Explain中的“Extra”
从上图我们得知，Extra的值有
NULL、Using index、Using where、Using index condition、Using filesort、Using temporary

🍃2.1 Using where

explain select * from account_user_base where id > 4;
Extra为Using where说明，SQL使用了where条件过滤数据。

🍃2.2 Using index

explain select id from account_user_base;
Extra为Using index说明，SQL所需要返回的所有列数据均在一棵索引树上，
而无需访问实际的行记录。

🍃2.3 Using index condition

explain select * from account_user_security t1, account_user_base t2 where t1.user_id = t2.id;
Extra为Using index condition说明，确实命中了索引，
但不是所有的列数据都在索引树上，还需要访问实际的行记录。

🍃2.4 Using filesort

explain select id from account_user_base order by nick_name;
Extra为Using filesort说明，得到所需结果集，需要对所有记录进行文件排序。
典型的，在一个没有建立索引的列上进行了order by，
就会触发filesort，常见的优化方案是，在order by的列上添加索引，避免每次查询都全量排序。

🍃2.5 Using temporary

explain select nick_name, COUNT(*) from account_user_base
GROUP BY nick_name order by nick_name;
Extra为Using temporary说明，需要建立临时表(temporary table)来暂存中间结果。
这类SQL语句性能较低，往往也需要进行优化。
典型的，group by和order by同时存在，且作用于不同的字段时，
就会建立临时表，以便计算出最终的结果集。

大家点赞、收藏、关注、评论啦 👇🏻👇🏻👇🏻微信公众号👇🏻👇🏻👇🏻