大佬教程收集整理的这篇文章主要介绍了MySQL执行计划【explain】详解，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
本文已经收录到github仓库，仓库用于分享Java相关知识总结，包括Java基础、MySQL、Springboot、mybatis、redis、rabbitMQ等等，欢迎大家提pr和star！
github地址：https://github.com/Tyson0314/Java-learning
gitlab地址：https://gitee.com/tysondai/Java-learning
本文主要讲述如何通过 explain 命令获取 SELEct 语句的执行计划，通过 explain 可以知道 SELEct 语句以下信息：
explain 执行计划包含字段信息如下：分别是 id、SELEct_type、table、partitions、type、possible_keys、key、key_len、ref、rows、filtered、Extra 12个字段。
通过explain extended + show warnings可以在原本explain的基础上额外提供一些查询优化的信息，得到优化以后的可能的查询语句（不一定是最终优化的结果）。
先搭建测试环境：
create table `blog` (
`blog_id` int nOT NULL AUTO_INCREMENT COMMENT '唯一博文id--主键',
`blog_title` varchar(255) NOT NULL COMMENT '博文标题',
`blog_body` text NOT NULL COMMENT '博文内容',
`blog_time` datetiR_20_11845@e NOT NULL COMMENT '博文发布时间',
`update_time` timestamp NULL DEFAULT NULL ON updatE CURRENT_TIMESTAMP,
`blog_state` int nOT NULL COMMENT '博文状态--0 删除 1正常',
`user_id` int nOT NULL COMMENT '用户id',
PRIMARY KEY (`blog_id`)
) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8
create table `user` (
`user_id` int nOT NULL AUTO_INCREMENT COMMENT '用户唯一id--主键',
`user_name` varchar(30) NOT NULL COMMENT '用户名--不能重复',
`user_Password` varchar(255) NOT NULL COMMENT '用户密码',
PRIMARY KEY (`user_id`),
KEY `name` (`user_name`)
) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8
create table `discuss` (
`discuss_id` int nOT NULL AUTO_INCREMENT COMMENT '评论唯一id',
`discuss_body` varchar(255) NOT NULL COMMENT '评论内容',
`discuss_time` datetiR_20_11845@e NOT NULL COMMENT '评论时间',
`user_id` int nOT NULL COMMENT '用户id',
`blog_id` int nOT NULL COMMENT '博文id',
PRIMARY KEY (`discuss_id`)
) ENGINE=InnoDB AUTO_INCREMENT=61 DEFAULT CHARSET=utf8
表示查询中执行SELEct子句或者操作表的顺序，id的值越大，代表优先级越高，越先执行。
explain SELEct discuss_body
from discuss
where blog_id = (
SELEct blog_id from blog where user_id = (
SELECT user_id from user where user_name = 'admin'));
三个表依次嵌套，发现最里层的子查询 id最大，最先执行。
表示 SELEct 查询的类型，主要是用于区分各种复杂的查询，例如：普通查询、联合查询、子查询等。
查询的表名，并不一定是真实存在的表，有别名显示别名，也可能为临时表。当from子句中有子查询时，table列是 <derivenN>的格式，表示当前查询依赖 id为N的查询，会先执行 id为N的查询。
查询时匹配到的分区信息，对于非分区表值为NULL，当查询的是分区表时，partitions显示分区表命中的分区情况。
查询使用了何种类型，它在 SQL优化中是一个非常重要的指标。
当表仅有一行记录时（系统表），数据量很少，往往不需要进行磁盘IO，速度非常快。比如，Mysql系统表proxies_priv在Mysql服务启动时候已经加载在内存中，对这个表进行查询不需要进行磁盘 IO。
单表操作的时候，查询使用了主键或者唯一索引。
多表关联查询的时候，主键和唯一索引作为关联条件。如下图的sql，对于user表（外循环）的每一行，user_role表（内循环）只有一行满足join条件，只要查找到这行记录，就会跳出内循环，继续外循环的下一轮查询。
查找条件列使用了索引而且不为主键和唯一索引。虽然使用了索引，但该索引列的值并不唯一，这样即使使用索引查找到了第一条数据，仍然不能停止，要在目标值附近进行小范围扫描。但它的好处是不需要扫全表，因为索引是有序的，即便有重复值，也是在一个非常小的范围内做扫描。
类似 ref，会额外搜索包含NULL值的行。
使用了索引合并优化方法，查询使用了两个以上的索引。新建comment表，id为主键，value_id为非唯一索引，执行explain SELEct content from comment where value_id = 1181000 and id > 1000;，执行结果显示查询同时使用了id和value_id索引，type列的值为index_merge。
有范围的索引扫描，相对于index的全索引扫描，它有范围限制，因此要优于index。像between、and、'>'、'<'、in和or都是范围索引扫描。
index包括SELEct索引列，order by主键两种情况。
order by主键。这种情况会按照索引顺序全表扫描数据，拿到的数据是按照主键排好序的，不需要额外进行排序。
SELEct索引列。type为index，而且extra字段为using index，也称这种情况为索引覆盖。所需要取的数据都在索引列，无需回表查询。
全表扫描，查询没有用到索引，性能最差。
此次查询中可能选用的索引。但这个索引并不定一会是最终查询数据时所被用到的索引。
此次查询中确切使用到的索引。
估算要找到所需的记录，需要读取的行数。评估SQL 性能的一个比较重要的数据，@H_907_25@mysql需要扫描的行数，很直观的显示 SQL 性能的好坏，一般情况下 rows 值越小越好。
存储引擎返回的数据在经过过滤后，剩下满足条件的记录数量的比例。
表示额外的信息说明。为了方便测试，这里新建两张表。
create table `t_order` (
`id` int nOT NULL AUTO_INCREMENT,
`user_id` int DEFAULT NULL,
`order_id` int DEFAULT NULL,
`order_status` Tinyint DEFAULT NULL,
`create_date` datetiR_20_11845@e DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_userid_order_id_createdate` (`user_id`,`order_id`,`create_date`)
) ENGINE=InnoDB AUTO_INCREMENT=99 DEFAULT CHARSET=utf8
create table `t_orderdetail` (
`id` int nOT NULL AUTO_INCREMENT,
`order_id` int DEFAULT NULL,
`product_name` varchar(100) DEFAULT NULL,
`cnt` int DEFAULT NULL,
`create_date` datetiR_20_11845@e DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_orderid_productname` (`order_id`,`product_name`)
) ENGINE=InnoDB AUTO_INCREMENT=152 DEFAULT CHARSET=utf8
查询的列未被索引覆盖，where筛选条件非索引的前导列。对存储引擎返回的结果进行过滤（Post-filter，后过滤），一般发生在MySQL服务器，而不是存储引擎层。
查询的列被索引覆盖，并且where筛选条件符合最左前缀原则，通过索引查找就能直接找到符合条件的数据，不需要回表查询数据。
查询的列被索引覆盖，但无法通过索引查找找到符合条件的数据，不过可以通过索引扫描找到符合条件的数据，也不需要回表查询数据。
包括两种情况：
where筛选条件不符合最左前缀原则
where筛选条件是索引列前导列的一个范围
查询的列未被索引覆盖，并且where筛选条件是索引的前导列，也就是用到了索引，但是部分字段未被索引覆盖，必须回表查询这些字段，Extra中为NULL。
索引下推（index condition pushdown，ICP），先使用where条件过滤索引，过滤完索引后找到所有符合索引条件的数据行，随后用 WHERE 子句中的其他条件去过滤这些数据行。
不使用ICP的情况（set optimizer_switch='index_condition_pushdown=off'），如下图，在步骤4中，没有使用where条件过滤索引：
使用ICP的情况（set optimizer_switch='index_condition_pushdown=on'）：
下面的例子使用了ICP：
explain select user_id, order_id, order_status
from t_order where user_id > 1 and user_id < 5G;
关掉ICP之后（set optimizer_switch='index_condition_pushdown=off'），可以看到extra列为using where，不会使用索引下推。
索引下推参考链接：索引下推例子 | 索引下推图解 |索引下推优化
使用了临时表保存中间结果，常见于 order by 和 group by 中。典型的，当group by和order by同时存在，且作用于不同的字段时，就会建立临时表，以便计算出最终的结果集。
文件排序。表示无法利用索引完成排序操作，以下情况会导致filesort：
Block nested Loop，需要进行嵌套循环计算。两个关联表join，关联字段均未建立索引，就会出现这种情况。比如内层和外层的type均为ALL，rows均为4，需要循环进行4*4次计算。常见的优化方案是，在关联字段上添加索引，避免每次嵌套循环计算。
本文参考了一些优秀的博客，感兴趣的可以了解下：
码字不易，如果本文写的不错，可以点个赞，让我知道，支持我写出更好的文章！
以上是大佬教程为你收集整理的MySQL执行计划【explain】详解全部内容，希望文章能够帮你解决MySQL执行计划【explain】详解所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。