mysql 联合索引原理详述

在一个市民信息表上，是否有必要将身份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) 的单字段索引。

一共3张表 knowledge , knowledge_question , knowledge_answer ，数据在 6000~10000 之间。 执行的语句： 执行时间约 10分钟 ，查看执行计划如下： 全部都是全表扫描，根据MySQL联表查询的算法 Nested-Loop Join ，MySQL查询的结果集是3张表的笛卡尔积，所以效率特别低。 耗时变成 20毫秒给Where条件建立索引，并不一定会使用。 比如：在表 knowledge 的字段 update 上建立索引 idx_time ： 结果执行上来看，并没有使用索引 idx_time 。 如果where条件从 k.update_time>'2019-01-03 12:00:00' 修改为 k.update_time='2019-01-03 12:00:00' （从 >变成 = ） 则会使用索引 idx_time在建立索引的时候，会遇到 Table Metadata Lock 的问题，可以先 show processlist ，找到占用表锁的连接，然后 kill 。

联合索引是由多个字段组成的索引。CREATE

[UNIQUE|FULLTEXT|SPATIAL]

INDEX

index_name[USING

index_type]ON

tbl_name

(index_col_name,...)index_col_name:col_name[(length)]

[ASC

|

DESC]如果你经常要用到多个字段的多条件查询，可以考虑建立联合索引，一般是除第一个字段外的其它字段不经常用于条件筛选情况，比如说a,b

两个字段，如果你经常用a条件或者a+b条件去查询，而很少单独用b条件查询，那么可以建立a,b的联合索引。

---