数据库之联合索引的最左匹配原则

觉得前边文字太多可以直接看下边的图解

一、组合索引的最左匹配原则的成因

• 我们创建联合索引的时候，mysql会对我们的建立索引的字段进行排序，比如顺序第一个字段先进行排序，然后对第二个字段进行排序，以此类推，就类似于order by 字段1，然后order by 字段2，第一个字段是绝对有序的，单单看其余索引的值就无序了，按照第一个索引的顺序来取出第二个索引的值，我们会发现，取出来的也是有序的（相对有序）。一般情况下，我们第二个字段就直接来判断了。
• 而且还有一个原因，当我们顺位第一个字段建立了索引后，一般B+树叶子节点是包含该行数据的，如果此时建立其他字段的索引，那么这个索引是没有包含到所有字段数据的，所以后边的索引最好都是进行更细部分的选择的，所以联合查询的时候，是优先最左匹配的。

二、原则细讲

• 最左匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询（>、<、between、like)就停止匹配，比如a = 3 and b =4 and d = 6，如果建立在（a,b,c,d)顺序的索引，d是用不到索引的，因为a值确定，b值顺序就相对确定，中间断开了c，线索就断了，d就无法确定，所有走到c就不走了。如果建立（a,b,d,c)的索引则都可以用到，其中a,b,d顺序可以任意调整，因为a，b，d都确定了，a—>b—>d过程中顺序都是确定的，即使我们交换他们位置，查询优化器，也能自动换成高效查询的顺序。

• =和in可以乱序，比如a =1 and b = 2 and c = 3，建立（啊a,b,c）索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式。

• 前边说到遇到范围查询就会停止匹配，这是因为范围查询前一项顺序是确定的，可以匹配上索引，到了范围查询这里，依旧可以匹配上索引，但是它的下一项，因为是相对于前一项的索引顺序才有的顺序，前一项是范围，那么这一项便不能确定顺序了。

可能图解会更加生动

（网上借图）

• 这是一个建立了（a,b）索引的B+树结构，可以看到a已经确定了绝对顺序，即1，1，2，2，3，3，而b则是1,2，1,4，1,2，是乱的，但是如果我们的条件是where a=1 and b=2我们再来看，a=1的取出来后，对应的b值为1,2，是有序的，然后便可以确定b了。
• 如果条件是where a>1 and b=2,此时a可以确定索引，但是a可以取2,3，他们对应的b又是无序的，b无法确定，所以到了范围查询，后边就不再匹配索引了

接着说匹配原则(详细举例）

假定有联合索引（a，b，c），（下边例子的索引都是这个）
做如下查询

select * from table_name where a = '1' 
select * from table_name where a = '1' and b = '2'  
select * from table_name where a = '1' and b = '2' and c = '3'

都从最左边开始连续匹配，都用到了索引

select * from table_name where  b = '2' 
select * from table_name where  c = '3'
select * from table_name where  b = '1' and c = '3' 

因为都没有走a，不能确定顺序，也就无法走索引，全都是全表扫描

select * from table_name where  a > 1 and a < 3 and b > 1;

根据上边说的遇到范围查询加粗样式就停，这里只能匹配a 的索引，后边的顺序都无法确定

select * from table_name where  a = 1 and b > 3;

这种情况，都是走索引的，b的顺序因为a的确定而相对确定

order by排序:

select * from table_name order by a,b,c limit 10;

上面这种都能走到索引，按照索引排序

select * from table_name order by b,c,a limit 10;

同时呢，它也是要符合最左原则，上面这种颠倒过来的，无法确定顺序，就不能走索引

select * from table_name where a =1 order by b,c limit 10;

这个a确定了，b和c可以走索引

select * from table_name order by a limit 10;
select * from table_name order by a,b limit 10;

这种情况也是走索引