前言
最近工作当中使用SQL的场景比较多,遇到了一些瓶颈,在SQL优化这方面做了一些了解。
在SQL应用中影响性能最多的就是慢查询,关于慢查询的优化,主要有这几个着手的方向:
- 监控sql执行情况,发邮件、短信报警,便于快速识别慢查询sql;
- 打开数据库慢查询日志功能;
- 简化业务逻辑;
- 代码重构、优化;
- 异步处理;
- sql优化;
- 索引优化。
其中解决慢查询最有效的手段就是索引优化。
大家应该都知道查看某条SQL的索引执行情况,最便捷的就是查看它的执行计划,而在SQL前面加上explain关键字,就能够看到它的执行计划,通过执行计划,我们可以清楚的看到表和索引执行的情况,索引有没有执行、索引执行顺序和索引的类型等。
索引优化步骤:
- 使用explain查看sql执行计划;
- 判断哪些索引使用不当;
- 优化sql,sql可能需要多次优化才能达到索引使用的最优值。
那么接下来记录一下关于查询计划如何使用和分析。
explain 介绍
下面是MySQL官方文档中关于 explain
语句的描述:
- EXPLAIN可以使用于 SELECT, DELETE, INSERT, REPLACE,和 UPDATE语句;
- 当EXPLAIN与可解释的语句一起使用时,MySQL将显示来自优化器的有关语句执行计划的信息。也就是说,MySQL解释了它将如何处理该语句,包括有关如何连接表以及以何种顺序连接表的信息;
- 当EXPLAIN与非可解释的语句一起使用时,它将显示在命名连接中执行的语句的执行计划;
- 对于SELECT语句, EXPLAIN可以显示的其他执行计划的警告信息;
- explain对于检测查询语句是否涉及到分区表十分有帮助;
- FORMAT选项可以指定执行计划的输出格式,默认情况下我们不指定FORMAT选项得到的结果是表格形式的,如果你指定以JSON的格式展现执行计划,只需要设定FORMAT参数为JSON。
explain详解
{EXPLAIN | DESCRIBE | DESC}
tbl_name [col_name | wild]
{EXPLAIN | DESCRIBE | DESC}
[explain_type]
{explainable_stmt | FORCONNECTION connection_id}
explain_type: {
EXTENDED
| PARTITIONS
| FORMAT = format_name
}
format_name: {
TRADITIONAL
| JSON
}
explainable_stmt: {
SELECTstatement
| DELETEstatement
| INSERTstatement
| REPLACEstatement
| UPDATEstatement
}
用一条简单的sql看看使用 explain
关键字的效果:
explain select * from test1;
执行结果:
从上图中看到执行结果中会显示12列信息,每列具体信息如下:
- id (select唯一标识);
- select_type (select类型);
- table (表名称);
- partitions (匹配的分区);
- type (连接类型);
- possible_keys (可能的索引选择);
- key (实际用到的索引);
- key_len (实际用到的索引长度);
- ref (与索引比较的列);
- rows (预计要检查的行数);
- filtered (按表条件过滤的行百分比);
- Extra (附加信息)。
接下来我们要搞懂这些列的含义。
id 列
该列的值是select查询中的序号,比如:1、2、3、4等,它决定了表的执行顺序。
某条sql的执行计划中一般会出现三种情况:
- id相同;
- id不同;
- id相同和不同都有。
接下来说明一下这三种情况下表的执行顺序。
1、id相同
执行sql如下:
explain select * from test1 t1 inner join test1 t2 on t1.id=t2.id
结果如下:
我们看到执行结果中的两条数据id都是1,是相同的。
这种情况表的执行顺序是怎么样的呢?
答案:从上到下执行,先执行表t1,再执行表t2。
执行的表要怎么看呢?
答案:看table字段,这个字段后面会详细解释。
2、id 不同
执行sql如下:
explain select * from test1 t1 where t1.id = (select id from test1 t2 where t2.id=2);
结果如下:
我们看到执行结果中两条数据的id不同,第一条数据是1,第二条数据是2。
这种情况表的执行顺序是怎么样的呢?
答案:序号大的先执行,这里会从下到上执行,先执行表t2,再执行表t1。
3、id 相同和不同都有
执行SQL如下:
explain
select t1.* from test1 t1
inner join (select max(id) mid from test1 group by id) t2
on t1.id=t2.mid
结果如下:
我们看到执行结果中三条数据,前面两条数据的的id相同,第三条数据的id跟前面的不同。
这种情况表的执行顺序又是怎么样的呢?
答案:先执行序号大的,先从下而上执行。遇到序号相同时,再从上而下执行。所以这个列子中表的顺序顺序是:test1、t1、
也许你会在这里心生疑问: 是什么鬼?
它表示派生表,后面会介绍到。
还有一个问题:id列的值允许为空吗?
答案在后面揭晓。
select_type 列
该列表示select的类型。具体包含了如下11种类型:
- SIMPLE (简单SELECT);
- PRIMARY (最外层SELECT);
- UNION (UNION后的第二个或更后面的SELECT);
- DEPENDENT UNION (UNION后的第二个或更后面的SELECT,取决于外部查询);
- UNION RESULT (UNION的结果);
- SUBQUERY (第一个SELECT子查询);
- DEPENDENT SUBQUERY (第一个SELECT子查询,取决于外部查询);
- DERIVED (派生表);
- MATERIALIZED (物子化查询);
- UNCACHEABLE SUBQUERY (子查询,其结果无法缓存);
- UNCACHEABLE UNION (UNION 后的第二个或更后面的SELECT,其结果无法缓存)。
其中常用的只有下面这几个:
类型 | 含义 |
---|---|
SIMPLE | 简单SELECT查询,不包含子查询和UNION |
PRIMARY | 复杂查询中的最外层查询,表示主要的查询 |
SUBQUERY | SELECT或WHERE列表中包含了子查询 |
DERIVED | FROM列表中包含的子查询,即衍生 |
UNION | UNION关键字之后的查询 |
UNION RESULT | 从UNION后的表获取结果集 |
下面看看这些SELECT类型具体是怎么出现的:
-
SIMPLE:执行如下SQL语句:
explain select * from test1;
结果如下:
它只在简单SELECT查询中出现,不包含子查询和UNION,这种类型比较直观就不多说了。 -
PRIMARY 和 SUBQUERY:执行SQL如下:
explain select * from test1 t1 where t1.id = (select id from test1 t2 where t2.id=2);
结果如下:
我们看到这条嵌套查询的sql中,最外层的t1表是PRIMARY类型,而最里面的子查询t2表是SUBQUERY类型。 -
DERIVED:执行sql如下:
explain select t1.* from test1 t1 inner join (select max(id) mid from test1 group by id) t2 on t1.id=t2.mid
结果如下:
最后一条记录就是衍生表,它一般是FROM列表中包含的子查询,这里是sql中的分组子查询。 -
UNION 和 UNION RESULT:执行SQL如下:
explain select * from test1 union select* from test2
结果为:
test2表是UNION关键字之后的查询,所以被标记为UNION,test1是最主要的表,被标记为PRIMARY。而<union1,2>
表示id=1
和id=2
的表union,其结果被标记为UNION RESULT。
UNION 和 UNION RESULT一般会成对出现。
此外,回答上面的问题:id列的值允许为空吗?
如果仔细看上面那张图,会发现id列是可以允许为空的,并且是在SELECT类型为: UNION RESULT的时候。
table 列
该列的值表示输出行所引用的表的名称,例如前面的 test1、test2等。
但也可以是一下值之一:
<unionM,N>
:具有和id值的行的M并集N;<derivedN>
:用于与该行的派生表结果id的值N。派生表可能来自(例如)FROM子句中的子查询;<subqueryN>
:子查询的结果,其id值为N。
partitions 列
该列的值表示查询将从中匹配记录的分区。
type 列
该列的值表示连接类型,是查看索引执行情况的一个重要指标。包含如下类型:
- system (表只有一条记录);
- const (通过索引一次就能找到);
- eq_ref (用于主键或唯一索引扫描);
- ref (用于非主键和唯一索引扫描);
- fulltext (全文扫描);
- ref_or_null (类似于ref,还会扫描null的数据);
- index_merge(多种索引合并的方式扫描);
- unique_subquery (类似于eq_ref,条件用于 in 子查询);
- index_subquery (类似于 unique_subquery,条件用于 in 子查询,但条件非主键或唯一索引);
- range (范围扫描);
- index (全索引扫描);
- ALL (全表扫描)。
执行结果中从最上面(system)到最下面(ALL)表示从最好到最坏。
我们需要重点掌握的是下面几种类型:
system > const > eq_ref > ref > range > index > ALL
在演示之前,先说明一下test2表中只有一条数据:
并且在code字段上面建了一个普通索引:
下面逐一看看常见的几个连接类型是怎么出现的:
-
SYSTEM:这种类型要求数据库表中只有一条数据,是const类型的一个特例,一般情况下是不会出现的。
-
CONST:通过一次索引就能找到数据,一般用于主键或唯一索引作为条件的查询sql中,执行sql如下:
explain select * from test2 where id=1;
结果为:
-
eq_ref:常用于主键或唯一索引扫描。执行sql如下:
explain select * from test2 t1 inner join test2 t2 on t1.id=t2.id;
结果如下:
此时,有人可能感到不解,const和eq_ref都是对主键或唯一索引的扫描,有什么区别?
答:const只索引一次,而eq_ref主键和主键匹配,由于表中有多条数据,一般情况下要索引多次,才能全部匹配上。 -
ref:常用于非主键和唯一索引扫描。执行sql如下:
explain select * from test2 where code = '001';
结果如下:
-
range:常用于范围查询,比如:between … and 或 In 等操作,执行sql如下:
explain select * from test2 where id between 1 and 2;
结果如下:
-
index:全索引扫描。执行sql如下:
explain select code from test2;
结果如下:
-
ALL:全表扫描。执行sql如下:
explain select * from test2;
结果如下:
possible_keys 列
该列表示可能的索引选择。
请注意,此列完全独立于表的顺序,这就意味着possible_keys在实践中,某些键可能无法与生成的表顺序一起使用。
如果此列是NULL,则没有相关的索引。在这种情况下,您可以通过检查该WHERE 子句以检查它是否引用了某些适合索引的列,从而提高查询性能。
key 列
该列表示实际用到的索引。
可能会出现possible_keys列为NULL,但是key不为NULL的情况。
演示之前,先看看test1表结构:
test1表中数据:
使用的索引:
code和name字段使用了联合索引。
执行sql如下:
explain select code from test1;
结果如下:
这条sql预计没有使用索引,但是实际上使用了全索引扫描方式的索引。
key_len 列
该列表示使用索引的长度。上面的key列可以看出有没有使用索引,key_len列则可以更进一步看出索引使用是否充分。不出意外的话,它是最重要的列。
有个关键的问题浮出水面:key_len是如何计算的?
决定key_len值的三个因素:
1.字符集
2.长度
3.是否为空
常用的字符编码占用字节数量如下:
字符编码 | 占用字节数 |
---|---|
GBK | 2 |
UTF8 | 3 |
ISO8859-1 | 1 |
GB2312 | 2 |
UTF-16 | 2 |
目前案例中数据库字符编码格式用的:UTF8占3个字节。
mysql常用字段占用字节数:
字段类型 | 占用字节数 |
---|---|
char[n] | n |
varchar[n] | n+2 |
tinyint | 1 |
smallint | 2 |
int | 4 |
bigint | 8 |
date | 3 |
timestamp | 4 |
datetime | 8 |
此外,如果字段类型允许为空则加1个字节。
上图中的 184是怎么算的?
184 = 30 * 3 + 2 + 30 * 3 + 2
再把test1表的code字段类型改成char,并且改成允许为空:
执行SQL如下:
explain select code from test1;
结果为:
key_len 计算方式:
183 = 30 * 3 + 1 + 30 * 3 + 2
还有一个问题:为什么这列表示索引使用是否充分呢,还有使用不充分的情况?
执行sql如下:
explain select code from test1 where code='001';
结果如下:
上图中使用了联合索引:idx_code_name,如果索引全匹配key_len应该是183,但实际上却是92,这就说明没有使用所有的索引,索引使用不充分。
ref 列
该列表示索引命中的列或者常量。
执行sql如下:
explain select * from test1 t1 inner join test1 t2 on t1.id=t2.id where t1.code='001';
结果为:
我们看到表t1命中的索引是const(常量),而t2命中的索引是列sue库的t1表的id字段。
rows 列
该列表示MySQL认为执行查询必须检查的行数。
对于InnoDB表,此数字是估计值,可能并不总是准确的。
filtered 列
该列表示按表条件过滤的表行的估计百分比。最大值为100,这表示未过滤行。值从100减小表示过滤量增加。
rows显示了检查的估计行数,rows × filtered
显示了与下表连接的行数。例如,如果 rows为1000且 filtered为50.00(50%),则与下表连接的行数为1000×50%= 500。
Extra 列
该字段包含有关MySQL如何解析查询的其他信息,这列还是挺重要的,但是里面包含的值太多,就不一一介绍了,只列举几个常见的。
-
Impossible WHERE
表示WHERE后面的条件一直都是false,
执行sql如下:explain select code from test1 where 'a' = 'b';
结果为:
-
Using filesort
表示按文件排序,一般是在指定的排序和索引排序不一致的情况才会出现。执行sql如下:
explain select code from test1 order by name desc;
结果为:
这里建立的是code和name的联合索引,顺序是code在前,name在后,这里直接按name降序,跟之前联合索引的顺序不一样。 -
Using index
表示是否用了覆盖索引,说白了它表示是否所有获取的列都走了索引。
上面那个例子中其实就用到了:Using index,因为只返回一列code,它字段走了索引。 -
Using temporary
表示是否使用了临时表,一般多见于order by 和 group by语句。执行sql如下:
explain select name from test1 group by name;
结果为:
-
Using where
表示使用了where条件过滤。 -
Using join buffer
表示是否使用连接缓冲。来自较早联接的表被部分读取到联接缓冲区中,然后从缓冲区中使用它们的行来与当前表执行联接。
索引优化的一般步骤:
-
先用慢查询日志定位具体需要优化的sql;
-
使用explain执行计划查看索引使用情况;
-
重点关注:
- key(查看有没有使用索引)
- key_len(查看索引使用是否充分)
- type(查看索引类型)
- Extra(查看附加信息:排序、临时表、where条件为false等)
一般情况下根据这4列就能找到索引问题。
-
根据上1步找出的索引问题优化sql;
-
再回到第2步。
参考文献
本文转自微信公众号 苏三说技术
:explain | 索引优化的这把绝世好剑,你真的会用吗?