慢查询应该怎么去合理优化

阿粉昨天把这个怎么把 SQL 是否命中是索引，以及把如何开启开启慢查询的方法已经分享给了大家，接下来我们就得分项一下，我们找到了自己的慢查询的 SQL ，那就应该想办法去优化，怎么能去优化自己的慢查询呢？

索引和慢查询

如何判断是否为慢查询？

MySQL判断一条语句是否为慢查询语句，主要依据SQL语句的执行时间，它把当前语句的执行时间跟 long_query_time 参数做比较，如果语句的执行时间 > long_query_time，就会把这条执行语句记录到慢查询日志里面。long_query_time 参数的默认值是 10s，该参数值可以根据自己的业务需要进行调整。

这个 long_query_time 是阿粉昨天说过的，开启慢查询日志，就能查询到。

我们这个时候已经找到了我们的慢查询的语句，接下来是不是就应该看看我们写的这个 SQL 是否命中了我们的索引呢？

如何判断是否应用了索引？

这不就用到阿粉上一篇文章中的一个语句了，

​​explain​​

直接通过 ​​explain​​ 来分析查看，检查结果中的 key 值，是否为NULL。

如果没有出现自己创建的索引，那么很肯定，这个 SQL 是没有走我们创建的索引的，那么他不慢 谁慢呢？

接下来阿粉给出一个 SQL ，看一下它是否会命中我们的索引呢？

select * from user where id > 2 ;

是否命中索引呢？

我们也都知道 ID 如果是主键的话，那么一定是有索引的，而这个 SQL 是否能命中索引，就得看你是怎么写的，我可以告诉大家，这个语句，确实命中了索引，但是索引并没有起作用。

为什么呢？

虽然使用了索引，但是还是从主键索引的最左边的叶节点开始向右扫描整个索引树，进行了 全表扫描，此时索引就失去了意义。

而像 ​​select * from user where id = 2; ​​这样的语句，才是我们平时说的使用了索引。它表示的意思是，我们使用了索引的快速搜索功能，并且有效地减少了扫描行数。

其实在这里，阿粉只想诠释一个事情，那就是查询是否使用索引，只是表示一个SQL语句的执行过程；而是否为慢查询，是由它执行的时间决定的，也就是说是否使用了索引和是否是慢查询两者之间没有必然的联系。

我们在使用索引时，不要只关注是否起作用，应该关心索引是否减少了查询扫描的数据行数，如果 扫描行数减少了，效率才会得到提升。对于一个大表，不止要创建索引，还要考虑索引过滤性，过 滤性好，执行速度才会快。

怎样提高索引的过滤性能呢？

假如有一个5000万记录的用户表，通过sex='男'索引过滤后，还需要定位3000万，SQL执行速度也 不会很快。其实这个问题涉及到索引的过滤性，比如1万条记录利用索引过滤后定位10条、100 条、1000条，那他们过滤性是不同的。索引过滤性与索引字段、表的数据量、表设计结构都有关 系。

这就要让我们具体的 SQL 具体的分析了，尽量能给我们的 Where 条件上面，增加索引，不管是普通索引还是联合索引，尽量的把自己的索引建立在你能命中的情况下。

慢查询是怎么导致的

慢查询原因：

• 全表扫描：explain分析type属性all
• 全索引扫描：explain分析type属性index
• 索引过滤性不好：靠索引字段选型、数据量和状态、表设计
• 频繁的回表查询开销：尽量少用select *，使用覆盖索引

所以你知道慢查询应该怎么去优化了么？

文章转载自公众号：  Java极客技术