MySQL 执⾏计划是 MySQL 查询优化器分析 SQL 查询时⽣成的⼀份详细计划,包括表如何连 接、是否⾛索引、表扫描⾏数等。通过这份执⾏计划,我们可以分析这条 SQL 查询中存在的 问题(如是否出现全表扫描),从⽽进⾏针对优化。
我们可以通过EXPLAIN
来查询我们SQL的执行计划。
SELECT查询的序列号,表示执行SELECT 子句的顺序(
Id相同,从上往下执行,Id不同,值越大越先执行。
)
查询类型,来区分简单查询、联合查询、⼦查询等。
常⻅的类型有:
- SIMPLE:简单查询,不包含表连接或⼦查询
- PRIMARY:主查询,外层的查询
- SUBQUERY:⼦查询中第⼀个
- SELECT UNION:UNION 后⾯的 SELECT 查询语句
- UNION RESULT:UNION 合并的结果
查询的表名(也可以是别名)
匹配的分区,没有分区的表为 NULL
扫描表的方式。
常见的类型有:(性能从上到下,越来越差)
表中只有一行数据(系统表),这是const类型的特殊情况;
最多返回一条匹配的数据在查询的最开始读取。
因为是通过主键
来查询的,然后我们的1也是常量级的,所以类型是const
。
在连接查询中
被驱动表
使用主键或者唯一键
进行连接的时候。(被驱动表
只返回一行数据),类似于外键查询。
在连接查询中
被驱动表
使用普通索引
进行连接的时候,或者在普通查询
的WHERE条件中使用索引
,基于这个索引来匹配表中所有的行。(也就是在查询前就知道可能会返回多条数据)
使用全文索引查询数据。
在
ref
的基础,额外添加了对NULL
值的查找。
在join
中也可使用
索引合并在
key
列中会显示所有使用到的索引。类似于有两个条件,这两个条件都有索引,用OR
进行连接的话,最后会通过两个索引查询的所有主键值来进行合并(并集
)。这个称之为`索引合并。
key
列中,可以看见我们使用了两个索引
使用索引进行范围查找。
像between
,>=
,>
,<
,<=
这种查询都是范围查询。
like
前缀的模糊查询也是范围查找。
虽然用到了索引,但是是扫描了所有的索引。
全表扫描。(注意:全表扫描并不代表就是最差的方案,就比方你本身就需要全部表的数据,你使用全表扫描还能用什么呢?)
这一列显示查询可能使用那些索引来查找。
explain 中有可能possible_keys中有值,但是我们的key中显示NULL的情况,这种因为表中的数据不多,MySQL认为对此查询帮助不大,选择了全表查询。
实际采用了那个索引。
如果没有使用索引时,我们可以通过force index
,ignore index
,来强制使用某个索引或者忽略某个索引。
表示使用
key
中索引的长度。
我们创建了一个b_c_d(三个字段的联合索引)。
这里可以用的b=4
来进行查询。key
列中存在我们的索引,但是注意key_len
是5,代表我们使用到了部分索引。
当我们使用b=4 and c=4
,这样里的key_len
是10
当我们使用b = 4 and c = 4 and d = 4
,这样里的key_len
是15
这里的计算方式是,1个int类型的索引是4个字节,又因为这个字段是允许为空的,所有的加+1位,则是5个字节。所有可以通过观察key_len
,来判断索引是否被充分使用。
如果是utf-8,则一个数字与一个字符占一个字节,一个汉字占3个字节
- char:如果存汉字就是3n字节
- varchar:如果存汉字则长度是3n+2字节,+2的2个字节用来存储字符串长度,因为字符串长度,
- tinyint:1字节
- smallint:2字节
- int:4字节
- bigint:8字节
- date:3字节
- timestamp:4字节
- datetime:8字节
注意:为空的字段,索引需要在额外+1,判断是否为NULL;
索引最大长度是768字节,当字符串过长时,mysql,会做一个类似于左前缀索引的处理,将前前半部分的字符提取出来做索引。
这一列显示了在key列记录的索引中,表查找值所用到的列或者常量。常见的有:
const
常量,字段名
表示mysql大概扫描的行数,这个并不是真正的结果集行数。
基于
row
扫描的行数,最后用到了百分之多少的数据
,优化可以根据这个来做文章,因为如果说有大量扫描的数据没有被使用,那么会降低查询效率。
字段通常回会显示更多的信息,可以帮助我们发现性能问题的所在。
使用
where
语句来进行过滤,并且使用的**条件未被索引**
覆盖。(表级的过滤)
查询的列
没有完全被索引覆盖
,且使用where
条件进行前置过滤。
表示直接通过索引即可返回所需的字段信息,不需要返回表。(
索引覆盖
)
就比方,需要返回一个二级索引值与主键值,使用where条件查询二级索引时,因为二级索引的叶子节点中存储的是主键值,所有不需要进行回表了。
表示需要额外的执行排序操作。数据较小时从内存排序,否则需要在磁盘完成排序。
意味着需要创建临时表保存中间结果
按树状结构输出我们的执行计划。
缩进越深越先执行,如果缩进相同从上往下执行.
EXPLAIN format = tree
SELECT
*
FROM
actor a
LEFT JOIN country b ON a.id = b.id
-> Nested loop left join (cost=1.60 rows=3)
-> Table scan on a (cost=0.55 rows=3)
-> Single-row index lookup on b using PRIMARY (Id=a.id) (cost=0.28 rows=1)
EXPLAIN format = json
SELECT
*
FROM
actor a
LEFT JOIN country b ON a.id = b.id
{
"query_block": {
"select_id": 1,
"cost_info": {
"query_cost": "1.60"
},
"nested_loop": [
{
"table": {
"table_name": "a",
"access_type": "ALL",
"rows_examined_per_scan": 3,
"rows_produced_per_join": 3,
"filtered": "100.00",
"cost_info": {
"read_cost": "0.25",
"eval_cost": "0.30",
"prefix_cost": "0.55",
"data_read_per_join": "456"
},
"used_columns": [
"id",
"name",
"update_time"
]
}
},
{
"table": {
"table_name": "b",
"access_type": "eq_ref",
"possible_keys": [
"PRIMARY"
],
"key": "PRIMARY",
"used_key_parts": [
"Id"
],
"key_length": "4",
"ref": [
"test.a.id"
],
"rows_examined_per_scan": 1,
"rows_produced_per_join": 3,
"filtered": "100.00",
"cost_info": {
"read_cost": "0.75",
"eval_cost": "0.30",
"prefix_cost": "1.60",
"data_read_per_join": "4K"
},
"used_columns": [
"Id",
"countryname",
"countrycode"
]
}
}
]
}
}
帮我们实际去执行一遍,并帮我们拿到实际的执行计划,及实际的值。
explain ANALYZE select * from T1 join T2 on T1.a = T2.a;
-> Nested loop inner join (cost=1.15 rows=2) (actual time=0.048..0.073 rows=3 loops=1)
-> Covering index scan on T1 using index_b (cost=0.45 rows=2) (actual time=0.034..0.043 rows=3 loops=1)
-> Single-row index lookup on T2 using PRIMARY (a=t1.a) (cost=0.30 rows=1) (actual time=0.009..0.009 rows=1 loops=3)
可以拿到实际上被MySQL优化器,优化过后的SQL。
很经典的样例就是,子查询中的Order By
被优化掉了。
因为我们这把排序放到了子查询内部,执行后发现我们的数据并没有按a来进行排序。
通过show warnings
可以看见实际执行的SQL中并没有Order by
方案一:在Order by 后面加个limit ,limit的数量比你原有的结果集大就行,
方案二:Order by放最外面。
MySQL针对子查询的优化,必须不是一个包含了limit
和order by
才会进行优化。