关于索引的最左前缀原则

今天学习了下关于索引的最左前缀的原理，小有成就感，在这里做一个学习记录，以后学习的时候可以直接找出来复习。

相信熟悉数据库的大佬们跟索引达人们肯定都了解最索引的左前缀原理，我在这里还是再重复一下吧，文章还会结合实际例子来说明最左前缀的原理。

实验工具；mysql 5.5 + sqlyog

索引的最左前缀原理：

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

比如：索引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语句，按照之前的理解，包含a字段，会走索引，但是是不是所有字段都走了索引呢？

我们来做个实验：

我这里有一个表：

  

建立了一个联合索引，prinIdAndOrder里面有三个字段  PARENT_ID, MENU_ORDER, MENU_NAME

接下来测试之前的语句：

ELECT 
  t.* 
FROM
  sys_menu t 
WHERE t.`PARENT_ID` = '0' 
  AND t.`MENU_NAME` = '系统工具'

这一句sql就相当于之前的select * from table where a = '1' and c= ‘2’这个sql语句了，我们来看看解释计划：

可以看到走了索引prinIdAndOrder,但是旁边的key_len=303,但道理key_len应该是大于303的，为什么呢？因为PARENT_ID字段的类型是varchar(100) NULL，所以key_len=100*3+2+1=303,但是还有MENU_NAME呢！具体的key_len的计算方法，大家可以百度，我的表的字符集是utf-8，不同字符集的表的计算方式不一样。这里的解释计划显示key_len只有303，说明只是走了字段PARENT_ID的索引，没有走MENU_NAME的索引。

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

另外还有一个特殊情况说明下，select * from table where a = '1' and b > ‘2’  and c='3' 这种类型的也只会有a与b走索引，c不会走。

原因如下：

索引是有序的，index1索引在索引文件中的排列是有序的，首先根据a来排序，然后才是根据b来排序，最后是根据c来排序，

像select * from table where a = '1' and b > ‘2’  and c='3' 这种类型的sql语句，在a、b走完索引后，c肯定是无序了，所以c就没法走索引，数据库会觉得还不如全表扫描c字段来的快。不知道我说明白没，感觉这一块说的始终有点牵强。

文中如果出现有误的地方麻烦大佬们指点。