通过explain查看MySQL索引是否正确引用

前言

前面我们已经知道了索引的基础知识及其构成,通过了解各个索引的运行机制从而保证灵活的选择合适恰当的索引,现在我们这篇文章主要分享一下我们设置好的索引是否如期的被SQL优化器正确的引用。

不清楚索引的基础知识及其构成和各个索引的运行机制的同志可以看我前面的文章

MySQL索引实现原理 和 索引类型-CSDN博客

如何恰当的选择MySQL索引 SQL优化实战版-CSDN博客

目录

explain命令基本介绍

优化器的逻辑

优化器选择索引的原理

出现了索引选择错误的情况解决方法

---

explain命令基本介绍

explain关键字可以模拟优化器执行 SQL 查询语句,从而知道MySQL是如何处理SQL语句的

按表的维度来展示执行计划的。多个联表查询,就返回多行执行计划,每行展示一个表的执行计划。

具体常用字段如下

id： 唯一的标识符

select_type： 查询类别,如简单查询、复杂查询等

table：表名

type：单表访问类型,就是查询性能的指标

        依次从最优到最差分别为：system >const -> eq_ref > ref > range > index > ALL

possible_keys：可能用到的索引

key：实际上使用的索引

key_len：实际使用到的索引长度,这个长度是数据类型的长度,如Byte是1 、varchar(100) 是100  这个字段可以让我们算出大概使用索引中的那些索引字段

rows：SQL优化器在没有执行SQL之前的预估扫描的条数

Extra：执行情况的说明和描述

从这些指标可以看到,SQL在执行过程中走了那些索引,如果是符合索引,复合索引用了那些索引字段,这段SQL加上索引的性能指标如何等常见需要分析索引的数值

优化器的逻辑

既然explain命令是模拟SQL优化器的,那么如果我们的索引没有按照我们预期的方式进行执行,此时需要排查的时候,如果懂得优化器的选择索引的逻辑,我们就有把握解决常见的问题: 如优化器选错了索引这些问题

优化器选择索引的原理

优化器选择索引的⽬的，是找到⼀个最优的执⾏⽅案，并⽤最⼩的代价去执⾏语句

优化器是看rows这个字段的数值,扫描行数越少,意味着访问磁盘次数越少,CPU资源消耗越少,查询速度越快,当然优化器看扫描行数只是选择索引的一个主要指标,还与是否使用临时表、是否排序等因素进行综合考虑

优化器是通过表中的总行数、表中的唯一值的数量和数据分布等多方面指标确定的一个预估结果

既然是预估结果,就会有错误的时候,即会有索引选择错误的时候。

出现了索引选择错误的情况解决方法

1、输入analyze table 表名 命令重新统计索引的统计信息

        适用于因统计信息过期导致的索引选择错误

2、使用force index强⾏指定这个SQL直接使用这个索引,不让优化器进行选择了

        这个只能是一个应急方案

3、既然会统计错误,说明MySQL的优化器统计这个索引的扫描行数是有误差的,可以相应的调整SQL语句,引导MySQL优化器使用我们期望的索引

        这个是根治方案