一个慢SQL优化

今天在观察慢sql统计的时候，发现了一个sql的平均耗时长，而且总的扫描行数大，分析对应表的DDL，发现此表中只有一个唯一索引index1(a,b,c)，但是在查询条件中没有带上a字段，导致这个查询sql没有走索引，从而导致了全表扫描。这里涉及到一个索引最左前缀原则，我们来一起看一下。

联合索引的最左前缀原则

下述摘自关于索引的最左前缀原则_zzx125的专栏-CSDN博客_最左前缀原则

通常我们在建立联合索引的时候，也就是对多个字段建立索引，mysql都会让我们选择索引的顺序，比如我们想在a,b,c三个字段上建立一个联合索引，我们可以选择自己想要的优先级，a、b、c,或者是b、a、c 或者是c、a、b等顺序。为什么数据库会让我们选择字段的顺序呢？不都是三个字段的联合索引么？这里就引出了数据库索引的最左前缀原理。

mysql建立多列索引(联合索引)有最左前缀的原则，即最左优先，如：

如果有一个2列的索引(col1,col2),则已经对(col1)、(col1,col2)上建立了索引；如果有一个3列索引(col1,col2,col3)，则已经对(col1)、(col1,col2)、(col1,col2,col3)上建立了索引；

比如：索引index1:(a,b,c)有三个字段，我们在使用sql语句来查询的时候，会发现很多情况下不按照我们想象的来走索引。

select * from table where c = '1' 这个sql语句是不会走index1索引的，select * from table where b =‘1’ and c ='2' 这个语句也不会走index1索引。

什么语句会走index1索引呢？

答案是：

select * from table where a = '1'select * from table where a = '1' and b = ‘2’select * from table where a = '1' and b = ‘2’ and c='3'

我们可以发现一个共同点，就是所有走索引index1的sql语句的查询条件里面都带有a字段，那么问题来了，index1的索引的最左边的列字段是a，是不是查询条件中包含a就会走索引呢？

select * from table where a = '1' and c= ‘2’这个sql语句了。

这也是最左前缀原理的一部分，索引index1:(a,b,c)，只会走a、a,b、a,b,c 三种类型的查询，其实这里说的有一点问题，a,c也走，但是只走a字段索引，不会走c字段。

​我是「翎野君」，感谢各位朋友的：点赞、收藏和评论，我们下期见。