explain | 索引优化的这把绝世好剑，你真的会用吗？

最新推荐文章于 2024-11-01 12:20:35 发布
最新推荐文章于 2024-11-01 12:20:35 发布
阅读量168 收藏
点赞数
分类专栏： 数据库+ES 文章标签： 数据库 mysql sql
原文链接：https://mp.weixin.qq.com/s/rPfNBKNo-ssDMzELGeQOqw
版权

转载：explain | 索引优化的这把绝世好剑，你真的会用吗？

对于互联网公司来说，随着用户量和数据量的不断增加，慢查询是无法避免的问题。

一般情况下如果出现慢查询，意味着接口响应慢、接口超时等问题，如果是高并发的场景，可能会出现数据库连接被占满的情况，直接导致服务不可用。

1. 前言

慢查询的确会导致很多问题，我们要如何优化慢查询呢？

主要解决办法有：

  • 监控sql执行情况，发邮件、短信报警，便于快速识别慢查询sql

  • 打开数据库慢查询日志功能

  • 简化业务逻辑

  • 代码重构、优化

  • 异步处理

  • sql优化

  • 索引优化

其他的办法先不说，后面有机会再单独介绍。今天我重点说说索引优化，因为它是解决慢查询sql问题最有效的手段。

如何查看某条sql的索引执行情况呢？

没错，在sql前面加上explain关键字，就能够看到它的执行计划，通过执行计划，我们可以清楚的看到表和索引执行的情况，索引有没有执行、索引执行顺序和索引的类型等。

索引优化的步骤是：

  1. 使用explain查看sql执行计划

  2. 判断哪些索引使用不当

  3. 优化sql，sql可能需要多次优化才能达到索引使用的最优值

既然索引优化的第一步是使用explain，我们先全面的了解一下它。

2. explain介绍

先看看mysql的官方文档是怎么描述explain的：

  • EXPLAIN可以使用于 SELECT， DELETE， INSERT， REPLACE，和 UPDATE语句。

  • 当EXPLAIN与可解释的语句一起使用时，MySQL将显示来自优化器的有关语句执行计划的信息。也就是说，MySQL解释了它将如何处理该语句，包括有关如何连接表以及以何种顺序连接表的信息。

  • 当EXPLAIN与非可解释的语句一起使用时，它将显示在命名连接中执行的语句的执行计划。

  • 对于SELECT语句， EXPLAIN可以显示的其他执行计划的警告信息。

3. explain详解

explain的语法：

{EXPLAIN | DESCRIBE | DESC}
    tbl_name [col_name | wild]

{EXPLAIN | DESCRIBE | DESC}
    [explain_type]
    {explainable_stmt | FOR CONNECTION connection_id}

explain_type: {
    EXTENDED
  | PARTITIONS
  | FORMAT = format_name
}

format_name: {
    TRADITIONAL
  | JSON
}

explainable_stmt: {
    SELECT statement
  | DELETE statement
  | INSERT statement
  | REPLACE statement
  | UPDATE statement
}

用一条简单的sql看看使用explain关键字的效果：

explain  select * from test1;

执行结果：

从上图中看到执行结果中会显示12列信息，每列具体信息如下：

说白了，我们要搞懂这些列的具体含义才能正常判断索引的使用情况。

话不多说，直接开始介绍吧。

3.1 id 列

该列的值是select查询中的序号，比如：1、2、3、4等，它决定了表的执行顺序。

某条sql的执行计划中一般会出现三种情况：

  1. id相同

  2. id不同

  3. id相同和不同都有

那么这三种情况表的执行顺序是怎么样的呢？

id相同

执行sql如下：

explain  select * from test1 t1 inner  join test1 t2 on t1.id=t2.id

结果：

我们看到执行结果中的两条数据id都是1，是相同的。

这种情况表的执行顺序是怎么样的呢？

答案：从上到下执行，先执行表t1，再执行表t2。

执行的表要怎么看呢？

答案：看table字段，这个字段后面会详细解释。

id不同

执行sql如下：

explain  select * from test1 t1 where t1.id = (select  id  from  test1 t2 where  t2.id=2);

结果：

我们看到执行结果中两条数据的id不同，第一条数据是1，第二条数据是2。

这种情况表的执行顺序是怎么样的呢？

答案：序号大的先执行，这里会从下到上执行，先执行表t2，再执行表t1。

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、

也许你会在这里心生疑问：< derived2> 是什么鬼？

它表示派生表，别急后面会讲的。

还有一个问题：id列的值允许为空吗？

答案在后面揭晓。

3.2 select_type列

该列表示select的类型。具体包含了如下11种类型：

但是常用的其实就是下面几个：

类型含义
SIMPLE简单SELECT查询，不包含子查询和UNION
PRIMARY复杂查询中的最外层查询，表示主要的查询
SUBQUERYSELECT或WHERE列表中包含了子查询
DERIVEDFROM列表中包含的子查询，即衍生
UNIONUNION关键字之后的查询
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的时候。

3.3 table列

该列的值表示输出行所引用的表的名称，比如前面的：test1、test2等。

但也可以是以下值之一：

  • <unionM,N>：具有和id值的行的M并集N。

  • <derivedN>：用于与该行的派生表结果id的值N。派生表可能来自（例如）FROM子句中的子查询 。

  • <subqueryN>：子查询的结果，其id值为N

3.4 partitions列

该列的值表示查询将从中匹配记录的分区

3.5 type列

该列的值表示连接类型，是查看索引执行情况的一个重要指标。包含如下类型：

执行结果从最好到最坏的的顺序是从上到下。

我们需要重点掌握的是下面几种类型：

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;  

结果：

3.6 possible_keys列

该列表示可能的索引选择。

请注意，此列完全独立于表的顺序，这就意味着possible_keys在实践中，某些键可能无法与生成的表顺序一起使用。

如果此列是NULL，则没有相关的索引。在这种情况下，您可以通过检查该WHERE 子句以检查它是否引用了某些适合索引的列，从而提高查询性能。

3.7 key列

该列表示实际用到的索引。

可能会出现possible_keys列为NULL，但是key不为NULL的情况。

演示之前，先看看test1表结构：

test1表中数据：

使用的索引：

code和name字段使用了联合索引。

执行sql如下：

explain select code  from test1;

结果：

这条sql预计没有使用索引，但是实际上使用了全索引扫描方式的索引。

3.8 key_len列

该列表示使用索引的长度。上面的key列可以看出有没有使用索引，key_len列则可以更进一步看出索引使用是否充分。不出意外的话，它是最重要的列。

有个关键的问题浮出水面：key_len是如何计算的？

决定key_len值的三个因素：

1.字符集

2.长度

3.是否为空

常用的字符编码占用字节数量如下：

目前我的数据库字符编码格式用的：UTF8占3个字节。

mysql常用字段占用字节数：

字段类型占用字节数
char(n)n
varchar(n)n + 2
tinyint1
smallint2
int4
bigint8
date3
timestamp4
datetime8

此外，如果字段类型允许为空则加1个字节。

上图中的 184是怎么算的？

184 = 30 * 3 + 2 + 30 * 3 + 2

再把test1表的code字段类型改成char，并且改成允许为空：

执行sql如下：

explain select code  from test1;

结果：

怎么算的？

183 = 30 * 3 + 1 + 30 * 3 + 2

还有一个问题：为什么这列表示索引使用是否充分呢，还有使用不充分的情况？

执行sql如下：

explain select code  from test1 where code='001';

结果：

上图中使用了联合索引：idx_code_name，如果索引全匹配key_len应该是183，但实际上却是92，这就说明没有使用所有的索引，索引使用不充分。

3.9 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字段。

3.10 rows列

该列表示MySQL认为执行查询必须检查的行数。

对于InnoDB表，此数字是估计值，可能并不总是准确的。

3.11 filtered列

该列表示按表条件过滤的表行的估计百分比。最大值为100，这表示未过滤行。值从100减小表示过滤量增加。

rows显示了检查的估计行数，rows× filtered显示了与下表连接的行数。例如，如果 rows为1000且 filtered为50.00（50％），则与下表连接的行数为1000×50％= 500。

3.12 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

表示是否使用连接缓冲。来自较早联接的表被部分读取到联接缓冲区中，然后从缓冲区中使用它们的行来与当前表执行联接。

4. 索引优化的过程

1.先用慢查询日志定位具体需要优化的sql

2.使用explain执行计划查看索引使用情况

3.重点关注：

key（查看有没有使用索引）

key_len（查看索引使用是否充分）

type（查看索引类型）

Extra（查看附加信息：排序、临时表、where条件为false等）

一般情况下根据这4列就能找到索引问题。

4.根据上1步找出的索引问题优化sql

5.再回到第2步

keep one's resolveY
关注
专栏目录
聊聊索引失效的10种场景，巨坑
lisu061714112的专栏
01-09 6741
前言 我之前写的一篇文章《聊聊sql优化的15个小技巧》，自发表之后，在全网广受好评，被很多大佬转载过，说明了这类文章的价值。 今天我接着上一期数据库的话题，更进一步聊聊索引的相关问题，因为索引是大家都比较关心的公共话题，确实有很多坑。 不知道你在实际工作中，有没有遇到过下面的这两种情况： 明明在某个字段上加了索引，但实际上并没有生效。 索引有时候生效了，有时候没有生效。 最近无意间获得一份BAT大厂大佬写的刷题笔记，一下子打通了我的任督二脉，越来越觉得算法没有想象中那么难了。 BAT大佬写的刷题笔记
（MySQL性能优化）Explain分析sql语句优劣
qq_38056704的博客
04-21 5660
在MySQL如何优化的问题上，怎么判断sql语句是否已经优化了呢，我们需要一个标准， Explain就是我们的标准！！ Explain是什么？Explain有什么用？   准备工作： 1.创建article表 插入数据 表结构：文章的信息：有作者、目录、阅读数、评论数、标题号、内容（简单的表，用于演示~）   实验过程： 1.要求查询出所有文章的信息（普通查询） ...
mysql explain ref列_mysql explain中的列
weixin_35697229的博客
01-27 633
参考：《高性能mysql》附录D EXPLAINMySql将Select查询分为简单和复杂类型，复杂类型分为3大类：简单子查询，所谓的派生表(在派生表的子查询)，以及UNION查询。列与其介绍id该列包含一个编号，标识SELECT所属的行。select_type该列显示了对应行是简单还是复杂的select(如果是后者，那么是三种复杂类型中哪一种)。simple：查询不包括子查询和UNION。pri...
mysql 全表扫描 视图_MySQL视图是否总是进行全表扫描？
weixin_29082143的博客
01-19 303
我正在尝试优化使用MySQL 5.1中的视图的查询.看来即使我从视图中选择1列,它也总是进行全表扫描.这是预期的行为吗？对于我在下面第一个查询中指定的表,视图只是SELECT“这些表中的所有列 – NOT *”.这是我从组成视图的查询中选择索引列的PromotionID时的解释输出.正如您所看到的,它与视图上的输出有很大不同.EXPLAIN SELECT pb.PromotionID FROM P...
union all 索引_关于索引你必须搞懂的概念
weixin_39640265的博客
12-04 1782
索引的定义索引用官方的话来讲，在关系型数据库中，是以一种物理的对数据库一列或多列值进行排序的存储结构，还包含了这些值数据页的指针用大白话来说，索引就相当于我们的字典的目录，而目录的中的页码就是对应着索引中指向数据页的指针，根据页码我们能快速的查到我们想要的内容。索引的数据结构当我们谈论mysql索引类型的时候，多半说的是B+Tree树(InnoDB)，当然了，不同的存...
＜explain＞索引优化的这把绝世好剑，你真的会用吗？
热门推荐
人生若只初相见@的博客
08-17 1万+
对于互联网公司来说，随着用户量和数据量的不断增加，慢查询是无法避免的问题。一般情况下如果出现慢查询，意味着接口响应慢、接口超时等问题。如果是高并发的场景，可能会出现数据库连接被占满的情况，直接导致服务不可用。 慢查询的确会导致很多问题，我们要如何优化慢查询呢？...
索引优化的这把绝世好剑--explain(荣耀典藏版)
人生若只初相见@的博客
07-13 4593
慢查询的确会导致很多问题，我们要如何优化慢查询呢？
explain | 索引优化的这把绝世好剑,你真的会用吗?
07-28
当谈到索引优化时，可以将其比喻为一把绝世好剑，因为它在数据库性能优化中扮演着非常重要的...所以，对于索引优化这把绝世好剑，了解和掌握它的使用方法是非常重要的，只有正确地使用索引，才能提升数据库的查询性能。
面试官：聊聊索引失效的10种场景，能回答一半就算过
m0_71777195的博客
09-09 310
今天我聊聊索引的相关问题，因为索引是大家都比较关心的公共话题，确实有很多坑。不知道你在实际工作中，有没有遇到过下面的这两种情况：明明在某个字段上加了索引，但实际上并没有生效。索引有时候生效了，有时候没有生效。今天就跟大家一起聊聊，mysql数据库索引失效的10种场景，给曾经踩过坑，或者即将要踩坑的朋友们一个参考。
聊聊接口性能优化的11个小技巧
JavaMonsterr的博客
07-28 366
接口性能优化对于从事后端开发的同学来说，肯定再熟悉不过了，因为它是一个跟开发语言无关的公共问题。该问题说简单也简单，说复杂也复杂。有时候，只需加个索引就能解决问题。有时候，需要做代码重构。有时候，需要增加缓存。有时候，需要引入一些中间件，比如mq。有时候，需要需要分库分表。有时候，需要拆分服务。等等。。。导致接口性能问题的原因千奇百怪，不同的项目不同的接口，原因可能也不一样。本文我总结了一些行之有效的，优化接口性能的办法，给有需要的朋友一个参考。...
WHERE条件中or与union引起的全表扫描的问题
weixin_30270889的博客
07-17 533
说起数据库的SQL语句执行效率的问题，就不得不提where条件语句中的or（逻辑或）引起的全表扫描问题，从而导致效率下降。 在以往绝大多数的资料中，大多数人的建议是使用union代替or，以解决由于使用了OR导致的全表扫描。然而，实际是不是如此呢？flymorn就拿5万多条数据的MSSQL数据库来测试。 在SQLServer查询分析器中键入...
union并不绝对比or的执行效率高
无天的博客
07-23 1万+
  我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。事实证明，这种说法对于大部分都是适用的。 1.select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=''2004-9-16'' or gid&gt;9990000 用时：68秒。扫描计数...
Mysql全表扫描
Hxuening的博客
09-01 5244
一，全表扫描是什么？ 全表扫描，就是一条一条记录的遍历，直到表中的最后一条记录。 在数据库中，对无索引的表进行查询一般称为全表扫描。全表扫描是数据库服务器用来搜寻表的每一条记录的过程，直到所有符合给定条件的记录返回为止。 在使用EXPLAIN分析SQL时，当列出执行计划表中type字段值为ALL时，代表需要全表扫描。 二，什么情况会进行全表扫描？ –1）条件中使用了null –2）使用or作为连接条件 –3）使用[not] in时 –4）使用模糊查询时 –5）使用!=或者<>时 –6）使用cou
oceanbase V4.2.2社区版集群离线部署
最新发布
king_harry的专栏
11-01 709
版本，选择是上传文件，包含oceanbase-ce、oceanbase-ce-libs、oceanbase-ce-utils。关闭时展示，为 OBProxy 集群的访问地址，仅用于生成租户的连接串，不影响实际使用，需要自主配置负载均衡，如果是 VIP 地址，还需要您自主申请并绑定到 OBProxy Server。集群配置选项卡—更多配置—更改系统内存保留选项，默认是30G，如果测试机内存只有16G，则需要调小，本测试调整为2G，这样ocp-server安装不会失败。自定义待管理的集群的名称。
基于vue框架的的汇生活家居商城的设计与实现bdjlq（程序+源码+数据库+调试部署+开发环境）系统界面在最后面。
h2345678的博客
10-29 1394
项目功能：商品分类,商品信息,用户。
VB.NET中如何利用Entity Framework Core进行轻量级ORM操作
2402_84885073的博客
11-01 424
实体类表示数据库中的表。你需要为每个表定义一个类，并在其中定义属性以映射到表的列。vb复制代码' 其他属性...End Class。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值