前言
对于互联网公司来说，随着用户量和数据量的一直减少，慢查问是无奈防止的问题。个别状况下如果呈现慢查问，意味着接口响应慢、接口超时等问题。如果是高并发的场景，可能会呈现数据库连贯被占满的状况，间接导致服务不可用。
慢查问确实会导致很多问题，咱们要如何优化慢查问呢？
次要解决办法有：
- 监控sql执行状况，发邮件、短信报警，便于疾速辨认慢查问sql
- 关上数据库慢查问日志性能
- 简化业务逻辑
- 代码重构、优化
- 异步解决
- sql优化
- 索引优化
其余的方法先不说，前面有机会再独自介绍。明天我重点说说索引优化，因为它是解决慢查问sql问题最无效的伎俩。
如何查看某条sql的索引执行状况呢？
没错，在sql后面加上explain关键字，就可能看到它的执行打算，通过执行打算，咱们能够分明的看到表和索引执行的状况，索引有没有执行、索引执行程序和索引的类型等。
索引优化的步骤是：
- 应用
explain查看sql执行打算 - 判断哪些索引使用不当
- 优化sql，sql可能须要屡次优化能力达到索引应用的最优值
既然索引优化的第一步是应用explain，咱们先全面的理解一下它。
explain介绍
先看看mysql的官网文档是怎么形容explain的：
- EXPLAIN能够应用于 SELECT， DELETE， INSERT， REPLACE，和 UPDATE语句。
- 当EXPLAIN与可解释的语句一起应用时，MySQL将显示来自优化器的无关语句执行打算的信息。也就是说，MySQL解释了它将如何解决该语句，包含无关如何连贯表以及以何种程序连贯表的信息。
- 当EXPLAIN与非可解释的语句一起应用时，它将显示在命名连贯中执行的语句的执行打算。
- 对于SELECT语句， EXPLAIN能够显示的其余执行打算的正告信息。
explain详解
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查问中的序号，比方：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如下：
explainselect t1.* from test1 t1inner join (select max(id) mid from test1 group by id) t2on t1.id=t2.mid后果：
咱们看到执行后果中三条数据，后面两条数据的的id雷同，第三条数据的id跟后面的不同。
这种情况表的执行程序又是怎么样的呢？
答案：先执行序号大的，先从下而上执行。遇到序号雷同时，再从上而下执行。所以这个列子中表的程序程序是：test1、t1、
兴许你会在这里心生疑难：<`derived2>` 是什么鬼？
它示意派生表，别急前面会讲的。
还有一个问题：id列的值容许为空吗？
答案在前面揭晓。
select_type列
该列示意select的类型。具体蕴含了如下11种类型：
然而罕用的其实就是上面几个：
上面看看这些SELECT类型具体是怎么呈现的：
1.SIMPLE
执行sql如下：```explain select * from test1;```后果：它只在简略SELECT查问中呈现，不蕴含子查问和UNION，这种类型比拟直观就不多说了。
2.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类型。
3.DERIVED
执行sql如下：```explain
select t1.* from test1 t1inner join (select max(id) mid from test1 group by id) t2on t1.id=t2.mid```后果：
最初一条记录就是衍生表，它个别是FROM列表中蕴含的子查问，这里是sql中的分组子查问。
4.UNION 和 UNION RESULT
执行sql如下：
```explainselect * from test1unionselect* 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 > range > index > ALL
在演示之前，先阐明一下test2表中只有一条数据：
并且code字段下面建了一个一般索引：
上面逐个看看常见的几个连贯类型是怎么呈现的：
- system
这种类型要求数据库表中只有一条数据，是const类型的一个特例，个别状况下是不会呈现的。
const
通过一次索引就能找到数据，个别用于主键或惟一索引作为条件的查问sql中，执行sql如下：
explain select * from test2 where id=1;
后果：
3.eq_ref
罕用于主键或惟一索引扫描。执行sql如下：
explain select * from test2 t1 inner join test2 t2 on t1.id=t2.id; 后果：
此时，有人可能感到不解，const和eq\_ref都是对主键或惟一索引的扫描，有什么区别？
答：const只索引一次，而eq_ref主键和主键匹配，因为表中有多条数据，个别状况下要索引屡次，能力全副匹配上。
4.ref
罕用于非主键和惟一索引扫描。执行sql如下：
explain select * from test2 where code = '001'; 后果：
5.range
罕用于范畴查问，比方：between ... and 或 In 等操作，执行sql如下：
explain select * from test2 where id between 1 and 2;后果：
6.index
全索引扫描。执行sql如下：
explain select code from test2后果：
7.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.是否为空
罕用的字符编码占用字节数量如下：
目前我的数据库字符编码格局用的：UTF8占3个字节。
mysql常用字段占用字节数：
此外，如果字段类型容许为空则加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，这就阐明没有应用所有的索引，索引应用不充沛。
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如何解析查问的其余信息，这列还是挺重要的，然而外面蕴含的值太多，就不一一介绍了，只列举几个常见的。
1.Impossible WHERE
示意WHERE前面的条件始终都是false，
执行sql如下：
explain select code from test1 where 'a' = 'b';后果：
2.Using filesort
示意按文件排序，个别是在指定的排序和索引排序不统一的状况才会呈现。
执行sql如下：
explain select code from test1 order by name desc;后果：
这里建设的是code和name的联结索引，程序是code在前，name在后，这里间接按name降序，跟之前联结索引的程序不一样。
3.Using index
示意是否用了笼罩索引，说白了它示意是否所有获取的列都走了索引。
下面那个例子中其实就用到了：Using index，因为只返回一列code，它字段走了索引。
4.Using temporary
示意是否应用了长期表，个别多见于order by 和 group by语句。
执行sql如下：
explain select name from test1 group by name;后果：
- Using where
示意应用了where条件过滤。
- Using join buffer
示意是否应用连贯缓冲。来自较早联接的表被局部读取到联接缓冲区中，而后从缓冲区中应用它们的行来与以后表执行联接。
索引优化的过程
1.先用慢查问日志定位具体须要优化的sql
2.应用explain执行打算查看索引应用状况
3.重点关注：
key（查看有没有应用索引）
key_len（查看索引应用是否充沛）
type（查看索引类型）
Extra（查看附加信息：排序、长期表、where条件为false等）
个别状况下依据这4列就能找到索引问题。
4.依据上1步找出的索引问题优化sql
5.再回到第2步
最初说一句(求关注，别白嫖我)
如果这篇文章对您有所帮忙，或者有所启发的话，帮忙扫描下发二维码关注一下，您的反对是我保持写作最大的能源。
求一键三连：点赞、转发、在看。
在公众号中回复：面试、代码神器、开发手册、工夫治理有超赞的粉丝福利，另外回复：加群，能够跟很多BAT大厂的前辈交换和学习。image.png
举荐浏览：
让人头痛的大事务问题到底要如何解决？
mybatis日志性能是如何设计的？
zuul如果两个filter的order一样，是如何排序的？
mysql的这几个坑你踩过没？真是防不胜防
线程池最佳线程数量到底要如何配置？
这8种保障线程平安的技术你都晓得吗？
springboot面试杀手锏-主动配置原理