MySQL的最左匹配原则是什么

最左匹配原则是应用于联合索引的规则。

对于以下表F：f1，f2，f3；建立了联合索引（f2，f3），那么我们在查询的时候如果是：

select * from F where f2 = ? and f3 = ?;
或 select * from F where f2 = ?;

那么是满足最左匹配的规则，就像我们查字典一样，我们需要先找到靠前的字母再往后找，这也是如此，需要先满足靠左的索引匹配才能继续进行

下面这个就不满足：

select * from F where f3 = ?;

当我们创建一个联合索引create [unique|fulltext] index 表名 (a, b, c)，我们为a、b、c创建了一个联合索引当我们进行查询时select * from 表名 where a = ? and b = ? and c = ?;这时就会通过索引快速查找。

如果select * from 表名 where a = ? and b = ?;满足最左前缀匹配那么也会走索引；如果select * from 表名 where a = ? and c = ?;这时a满足最左匹配，而c不满足所以对a的查找会走索引而c不会走。

原理：这和联合索引在b+树上的存储有关，还是用字典举例，我们为什么能快速定位一个字，这时因为字典上的字的存储是有规律的，字典按照每一位的字典序大小排序（从第一位一直比到最后）。联合索引的存储也类似，先根据f2来排序，如果f2相同在根据f3来排序，所以这就是我们不能跳过前面索引的原因。

最左匹配失效：大部分导致索引失效的情景都会导致最左匹配失效，有个要注意的就是如果对靠左的索引使用了不含等值的范围查询（>,<,like(%xx)）会导致查询结果无序，后续索引自然无法使用。

MySQL（8.0.26）的优化：对于上面 select * from F where f3 = ?; 这条语句因为我们跳过的f2所以无法走索引得走全表查询，但是如果我非要走索引呢（索引的效率多高啊），所以mysql的优化器就想怎么才能走索引呢，我们是因为跳过f2才导致索引失效的，那么我补上f2不就行了吗，因此优化器会隐式的帮我们补上，例如：.....where f2 = 1 and f3 = ?; .....where f2 = 2 and f3 = ?;这样不就又可以走索引了吗。但是很显然这要求f2的值不能太多如果有个几万个那还不如直接全表算了，所以条件比较苛刻。

tip：但是在实际使用的时候有时虽然不满足使用索引的条件但是任然会使用索引，最典型的就是索引覆盖，如果二级索引中包含了查询的所有字段就会走二级索引而不是主键索引，mysql的优化器会帮我们优化执行计划如：

当查询条件都在时，无论顺序都是会走索引的，
select * from 表名 where b = ? and a = ? and  c = ?; 
与 select * from 表名 where a = ? and c = ? and b = ? ;
都会走索引。

所以实际情况需要自己通过explain分析。