深入慢sql优化

前言

上文总结了Mysql数据库的基础知识及概念。本文针对慢SQL的识别与优化进行深度探究，正巧前段时间遇到了一个相关的业务问题，有少许心得，跟大家分享。

为什么要进行sql优化

对于一个新业务而言，数据量和用户量相对较小，很多情况下甚至单库单表就足以满足当下业务需求。而随着时间的积累，业务数据量的增多，可能会开始进行分库分表，当数据量持续增加后，架构不发生明显变化的前提下，SQL的执行效率对程序的运行效率的影响逐渐增大，系统可能出现卡顿、延迟甚至超时报错。此时对SQL的优化就很有必要。

慢sql的现象及原因总结

一个风和日丽的下午，小明突然接到客服电话，说接到大量用户投诉，页面打不开了，一直加载中。小明心里一紧，最近就自己发布了新代码，加了一个新功能，不会是那部分代码出现了问题了吧 ? ! !
赶紧切流到备库，回滚代码。然后查看错误日志，发现数据库连接池报了大量的超时错误，这种情况一般有两种可能：

• 一种是数据库或者连接数据库的网络发生了某种意外，导致数据库连接不上了，达到超时时间了；
• 另一种可能是有大量线程执行慢查询，老线程还在执行查询，新线程只能陷入等待，等待太久达到超时时间了。

最终定位定位到是数据库慢查询的问题导致这个故障。一个高频查询“没有命中索引，导致全表扫描”，单个查询最少就需要一秒多，所以大量查询请求堆积，超时。

如何分析sql慢的原因

通过Explain判断是否走索引

对于低性能的SQL语句的定位，最重要也是最有效的方法就是使用执行计划，MySQL提供了explain命令来查看语句的执行计划。 我们知道，不管是哪种数据库，或者是哪种数据库引擎，在对一条SQL语句进行执行的过程中都会做很多相关的优化，对于查询语句，最重要的优化方式就是使用索引。 而执行计划，就是显示数据库引擎对于SQL语句的执行的详细情况，其中包含了是否使用索引，使用什么索引，使用的索引的相关信息等。

id : 唯一标识，id不同，id值越大优先级越高，越先被执行
select_type : 表示执行类型。如这里的simple表示无其他复杂查询
type(非常重要，可以看到有没有走索引)：

• ALL 扫描全表数据
• index 遍历索引
• range 索引范围查找
• index_subquery 在子查询中使用 ref
• unique_subquery 在子查询中使用 eq_ref
• ref_or_null 对Null进行索引的优化的
• ref fulltext使用全文索引
• ref 使用非唯一索引查找数据
• eq_ref 在join查询中使用PRIMARY KEY or UNIQUE NOT NULL索引关联。

possible_keys：表示可能用到的索引，但不一定真正会用到
key:(重要，真正走的索引)
extra:（重