一個慢SQL優化
今天在觀察慢sql統計的時候，發現了一個sql的平均耗時長，而且總的掃描行數大，分析對應表的DDL，發現此表中只有一個唯一索引index1(a,b,c)，但是在查詢條件中沒有帶上a字段，導致這個查詢sql沒有走索引，從而導致了全表掃描。這里涉及到一個索引最左前綴原則，我們來一起看一下。
聯合索引的最左前綴原則
下述摘自https://blog.csdn.net/zzx125/article/details/79678770
通常我們在建立聯合索引的時候，也就是對多個字段建立索引，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字段。