MySQL联合索引与最左匹配原则的实现

前言：

最左匹配原则在我们 MySQL 开发过程中和面试过程中经常遇到，为了加深印象和理解，我在这里把 MySQL 的最左匹配原则详细的讲解一下，包括它的原理以及是否导致索引失效的场景。

在讲解 MySQL 的最左匹配原则之前，我们需要了解一下 MySQL 的联合索引（也称复合索引），因为最左匹配原则是在联合索引的基础上产生的，没有联合索引就没有最左匹配原则这个概念。

一、联合索引

1、什么是联合索引

我们知道，单值索引指的是只使用一个字段作为索引字段的索引，而联合索引则是使用多个字段来共同构建成一个索引：

KEY idx_abc (a, b, c);

2、为什么要使用联合索引

2-1、减少开销

建一个联合索引 (a, b, c)，实际上相当于建了 (a)、(a, b)、(a, b, c) 三个索引。这样我们就不需要创建 (a)、(b)、(c) 三个单值索引了。我们知道，每多一个索引，都会增加数据库写操作的开销和磁盘空间的开销，对于大量数据的表，使用联合索引会大大的减少开销！

2-2、覆盖索引

对联合索引 (a, b, c)，如果有如下的 SQL：select a, b, c from test where a=1 and b=2。那么 MySQL 可以直接通过遍历索引取得数据，而无需回表，从而减少了很多的随机 IO 操作。而减少 IO 操作，而减少随机 IO 是 DBA 主要的优化策略，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。

2-3、提高效率

联合索引的字段越多，通过索引筛选出的数据越少。假如有 1000W 条数据的表，有如下 sql: select * from table where a=1 and b=2 and c=3，假设每个条件可以筛选出 10% 的数据，如果只有单值索引，那么通过该索引能筛选出 1000W * 10% = 100w 条数据，然后再回表从 100w 条数据中找到符合 b=2 and c=3 的数据，然后再排序，再分页。

但如果是联合索引，则通过索引直接筛选出的数据为：1000w * 10% * 10% * 10% = 1w，这效率的提升可想而知！

二、最左匹配原则

1、最左匹配原则的规则

在联合索引当中，索引匹配时：最左字段优先，以最左边的字段为起点任何连续的字段索引都能匹配上，如果遇到范围查询 (>、<、between、like) 时就会停止匹配。

2、索引是否生效的场景

是否满足最左匹配原则是衡量联合索引命中与否的依据。存在的场景比较多，假设我们创建了以 a, b, c 三个字段的联合索引 idx_abc(a, b, c)，下面我们分别展开讨论索引是否失效的场景。

2-1、全字段全值匹配

索引的全部字段都在查找条件当中，并且都是使用 = 进行全值匹配的情况下，索引是命中生效的：

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

虽然 where 子句几个搜索条件顺序调换了，但不影响查询结果，这是由于 MySQL 的查询优化器会自动调整 where 子句的条件顺序以使用适合的索引，所以 MySQL 不存在 where 子句的顺序问题而造成索引失效。

2-2、从左到右按顺序匹配

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'

只要是按照联合索引创建的字段从左到右的顺序依次使用，不管使用其中多少个字段，都会命中索引。

2-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 字段的情况就是违背最左匹配原则的典型例子，结果就是没有用到索引（索引失效）。

因为缺失了最左边的字段，导致索引数据结构 B+ 树不知道第一步该查哪个节点，从而需要去全表扫描了。在建立搜索树的时候 a 就是第一个比较因子，必须要先根据 a 来搜索，进而才能往后继续查询 b 和 c。

2-4、缺失中间的字段

假如去掉中间的字段，保留最左边和右边的字段（就是我们说的索引字段不连续）：

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

结果就是只用到了 a 列的索引，而 b 列和 c 列都没有用到。

因为在这种情况下进行数据检索时，B+ 树可以用 a 来指定第一步的搜索方向，但由于下一个字段 b 的缺失，所以只能先把 a = 1 的数据主键 ID 都找出来，然后通过查到的主键 ID 回表查询相关行，再去匹配 c 值的数据了。当然，这至少把 a = 1 的数据筛选出来了，总比直接全表扫描好多了

2-5、匹配范围值

出现匹配范围值的情况可能比较复杂或难以理解，但我们只需要牢记最左匹配原则的规则：遇到范围查询 (>、<、between、like) 时就会停止匹配。

比如下面这种情况：

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

这种情况下，由于 a 是等值匹配，所以 B+ 树走完 a 索引之后 b 还是有序的，但走完 b 索引之后，由于 b 是范围匹配，所以此时 c 已经是无序的了，最终只使用了 (a, b) 两个索引（由于此时 c 就没法走索引，所以优化器只能根据 a, b 得到数据的主键 ID 回表查询，最终影响了执行效率）。

再比如下面的情况：

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

当多个列同时进行范围查找时，只有对索引最左边的那个列进行范围查找才用到 B+ 树索引，也就是只有 a 用到索引，在 a > 1 和 1 < a < 3 的范围内 b 是无序的，所以 b 不能用索引，找到 a 的记录后，只能根据条件 b > 1 继续逐条过滤。

2-6、like 语句匹配问题

当索引列是字符型，并且使用了 like 语句进行模糊查询时，如果通配符 % 不出现在开头，则可以用到索引，否则将会违背了最左匹配原则，而不会使用索引，走的是全表扫描：

select * from table_name where a like 'As%';   //走索引查询
select * from table_name where a like '%As';   //全表查询
select * from table_name where a like '%As%';  //全表查询

我们先了解一下字符型字段的比较规则：当列是字符型的话，它的比较规则是先比较字符串的第一个字符，第一个字符小的那个字符串就比较小，如果两个字符串第一个字符相同，那就再比较第二个字符，依次类推。

所以，如果通配符 % 出现在开头，B+ 树则无法进行比较匹配，进而导致索引失效。

3、解决文件排序的问题

当我们对查询的数据进行 order by 排序时，一般情况下，我们是先把数据记录加载到内存中，再用一些排序算法，比如快速排序，归并排序等在内存中对这些记录进行排序。但有时候查询的结果集太大不能在内存中进行排序时，需要暂时借助磁盘空间存放中间结果，排序操作完成后再把排好序的结果返回客户端。Mysql 把这种在磁盘上进行排序的方式称为文件排序（Filesort）。

文件排序是非常慢非常耗性能的，但如果 order by 子句用到了索引列，就有可能避免文件排序的问题：

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

因为 B+ 树索引本身就是按照上述规则排序的，准确来说就是：索引是有序的，所以得到的结果集已经排好序了，不用再进行额外的排序操作。

注意：order by 的子句后面的字段顺序也必须按照索引字段的顺序给出，不能颠倒顺序（MySQL 不会自动调整排序字段的顺序）。

下面这种就是因为颠倒顺序而没有使用索引的情况：

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

下面这种是用到部分索引的情况：

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

下面这种情况，由于联合索引左边列为常量，后边的列排序可以用到索引：

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

 到此这篇关于MySQL联合索引与最左匹配原则的实现的文章就介绍到这了,更多相关MySQL联合索引与最左匹配原则内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！