Mysql中什么是最左前缀原则？

a.b.c三个分别建立索引，就是普通索引或单个索引。

（a.b.c）整体建立索引，就是复合索引。因为“最左前缀原则”所以其实相当于创建了(a,b,c)，(a,b)、(c)三个索引。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。例：

select * from test where a='11'

select * from test where a='11' and b=1

select * from test where a='11' and b=1 and c=2.0

以上有索引

select * from test where b=11

select * from test where b=1 and c=2.0

以上无索引

MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，以最左边的为起点任何连续的索引都能匹配上,同时遇到范围查询(>、<、between、like)就会停止匹配。。

我先说一下，我从看来的文章里理解的内容。

例如，我创建了一张表，有A、B、C三个属性。我们在此基础上创建联合索引（A、B、C），实际上这是创建了三个索引，（A）（A、B）（A、B、C）。我们通过索引查询的时候，就可以查（A=？、B=?），Sql语言甚至有自动检测功能，当你输入的顺序不是按照索引的顺序时，例如，（B＝？，A＝？，C＝？），这也是可以按照索（A、B、C）引来进行查找的。但是如果是查找（B＝？，C＝？）的时候，这时用的不是创建的索引（A、B、C），而是全索引，这是跟它的底层原理相关的，下面再谈。如果又有一个查询（A、B、C），不过B是范围查找的话，索引也只到A、B，因为B是范围查找，后面的字段就会停止匹配。

从上面可以看出最左前缀原则是在检索数据时按照规定的索引顺序来的。

这里有一片文章，介绍的比较详细，大家可以去看看。文章中有实例的测试，更加详细。

网页链接

底层原理

首先要知道，最左前缀原则是针对联合索引的，索引就要知道联合索引的实现原理。

它的底层是一个B+树，但键值数是大于1的。而构建一个B+树就只能根据一个键值来进行，所以数据库依据联合索引最左的字段来构建B+树。

下面是一个（A、B）的联合索引。

可以看到A是有顺序的，但是B不是，B的顺序是建立在A的基础上的。所以最左前缀原则是根据索引先匹配A，在匹配B。如果没有A，直接查找B的话，这就用不到（A、B）索引，而是全索引。

在一个市民信息表上，是否有必要将身份z号

和名字建立联合索引？

假设这个市民表的定义是这样的：

CREATE TABLE `tuser` (

`id` int(11) NOT NULL,

`id_card` varchar(32) DEFAULT NULL,

`name` varchar(32) DEFAULT NULL,

`age` int(11) DEFAULT NULL,

`ismale` tinyint(1) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `id_card` (`id_card`),

KEY `name_age` (`name`,`age`)

) ENGINE=InnoDB

我们知道，身份z号是市民的唯一标识。也就是说，如果有根据身份z号查询市民信息的需求，

我们只要在身份z号字段上建立索引就够了。而再建立一个（身份z号、姓名）的联合索引，是

不是浪费空间？

如果现在有一个高频请求，要根据市民的身份z号查询他的姓名，这个联合索引就有意义了。它

可以在这个高频请求上用到覆盖索引，不再需要回表查整行记录，减少语句的执行时间。

当然，索引字段的维护总是有代价的。因此，在建立冗余索引来支持覆盖索引时就需要权衡考虑

了。这正是业务 DBA，或者称为业务数据架构师的工作。

最左前缀原则

看到这里你一定有一个疑问，如果为每一种查询都设计一个索引，索引是不是太多了。如果我现

在要按照市民的身份z号去查他的家庭地址呢？虽然这个查询需求在业务中出现的概率不高，但

总不能让它走全表扫描吧？反过来说，单独为一个不频繁的请求创建一个（身份z号，地址）的

索引又感觉有点浪费。应该怎么做呢？

这里，我先和你说结论吧。B+ 树这种索引结构，可以利用索引的“最左前缀”，来定位记录。

为了直观地说明这个概念，我们用（name，age）这个联合索引来分析。

                     图 2 （name，age）索引示意图

可以看到，索引项是按照索引定义里面出现的字段顺序排序的。

当你的逻辑需求是查到所有名字是“张三”的人时，可以快速定位到 ID4，然后向后遍历得到所有

需要的结果。

如果你要查的是所有名字第一个字是“张”的人，你的 SQL 语句的条件是"where name like ‘张

%’"。这时，你也能够用上这个索引，查找到第一个符合条件的记录是 ID3，然后向后遍历，直

到不满足条件为止。

可以看到，不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。这个最左

前缀可以是联合索引的最左 N 个字段，也可以是字符串索引的最左 M 个字符。

基于上面对最左前缀索引的说明，我们来讨论一个问题：在建立联合索引的时候，如何安排索引

内的字段顺序。

这里我们的评估标准是，索引的复用能力。因为可以支持最左前缀，所以当已经有了 (a,b) 这个

联合索引后，一般就不需要单独在 a 上建立索引了。因此，第一原则是，如果通过调整顺序，可

以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。

所以现在你知道了，这段开头的问题里，我们要为高频请求创建 (身份z号，姓名）这个联合索

引，并用这个索引支持“根据身份z号查询地址”的需求。

那么，如果既有联合查询，又有基于 a、b 各自的查询呢？查询条件里面只有 b 的语句，是无法

使用 (a,b) 这个联合索引的，这时候你不得不维护另外一个索引，也就是说你需要同时维护

(a,b)、(b) 这两个索引。

这时候，我们要考虑的原则就是空间了。比如上面这个市民表的情况，name 字段是比 age 字段

大的 ，那我就建议你创建一个（name,age) 的联合索引和一个 (age) 的单字段索引。

---