05 | 深刻浅出索引（下）

在上一篇文章中，我和你介绍了InnoDB索引的数据结构模型，今天咱们再继续聊聊跟MySQL索引有关的概念。

在开始这篇文章以前，咱们先来看一下这个问题：

在下面这个表T中，若是我执行 select * from T where k between 3 and 5，须要执行几回树的搜索操做，会扫描多少行？

下面是这个表的初始化语句。

mysql> create table T (
ID int primary key,
k int NOT NULL DEFAULT 0, 
s varchar(16) NOT NULL DEFAULT '',
index k(k))
engine=InnoDB;

insert into T values(100,1, 'aa'),(200,2,'bb'),(300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');

图1 InnoDB的索引组织结构

如今，咱们一块儿来看看这条SQL查询语句的执行流程：

1. 在k索引树上找到k=3的记录，取得 ID = 300；

2. 再到ID索引树查到ID=300对应的R3；

3. 在k索引树取下一个值k=5，取得ID=500；

4. 再回到ID索引树查到ID=500对应的R4；

5. 在k索引树取下一个值k=6，不知足条件，循环结束。

在这个过程当中，回到主键索引树搜索的过程，咱们称为回表。能够看到，这个查询过程读了k索引树的3条记录（步骤一、3和5），回表了两次（步骤2和4）。

在这个例子中，因为查询结果所须要的数据只在主键索引上有，因此不得不回表。那么，有没有可能通过索引优化，避免回表过程呢？

覆盖索引

若是执行的语句是select ID from T where k between 3 and 5，这时只须要查ID的值，而ID的值已经在k索引树上了，所以能够直接提供查询结果，不须要回表。也就是说，在这个查询里面，索引k已经“覆盖了”咱们的查询需求，咱们称为覆盖索引。

因为覆盖索引能够减小树的搜索次数，显著提高查询性能，因此使用覆盖索引是一个经常使用的性能优化手段。

须要注意的是，在引擎内部使用覆盖索引在索引k上其实读了三个记录，R3~R5（对应的索引k上的记录项），可是对于MySQL的Server层来讲，它就是找引擎拿到了两条记录，所以MySQL认为扫描行数是2。

备注：关于如何查看扫描行数的问题，我将会在第16文章《如何正确地显示随机消息？》中，和你详细讨论。

基于上面覆盖索引的说明，咱们来讨论一个问题：在一个市民信息表上，是否有必要将身份证号和名字创建联合索引？

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

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

咱们知道，身份证号是市民的惟一标识。也就是说，若是有根据身份证号查询市民信息的需求，咱们只要在身份证号字段上创建索引就够了。而再创建一个（身份证号、姓名）的联合索引，是否是浪费空间？

若是如今有一个高频请求，要根据市民的身份证号查询他的姓名，这个联合索引就有意义了。它能够在这个高频请求上用到覆盖索引，再也不须要回表查整行记录，减小语句的执行时间。

固然，索引字段的维护老是有代价的。所以，在创建冗余索引来支持覆盖索引时就须要权衡考虑了。这正是业务DBA，或者称为业务数据架构师的工做。

最左前缀原则

看到这里你必定有一个疑问，若是为每一种查询都设计一个索引，索引是否是太多了。若是我如今要按照市民的身份证号去查他的家庭地址呢？虽然这个查询需求在业务中出现的几率不高，但总不能让它走全表扫描吧？反过来讲，单独为一个不频繁的请求建立一个（身份证号，地址）的索引又感受有点浪费。应该怎么作呢？

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

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

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

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

当你的逻辑需求是查到全部名字是“张三”的人时，能够快速定位到ID4，而后向后遍历获得全部须要的结果。

若是你要查的是全部名字第一个字是“张”的人，你的SQL语句的条件是"where name like ‘张%’"。这时，你也可以用上这个索引，查找到第一个符合条件的记录是ID3，而后向后遍历，直到不知足条件为止。

能够看到，不仅是索引的所有定义，只要知足最左前缀，就能够利用索引来加速检索。这个最左前缀能够是联合索引的最左N个字段，也能够是字符串索引的最左M个字符。

基于上面对最左前缀索引的说明，咱们来讨论一个问题：在创建联合索引的时候，如何安排索引内的字段顺序。

这里咱们的评估标准是，索引的复用能力。由于能够支持最左前缀，因此当已经有了(a,b)这个联合索引后，通常就不须要单独在a上创建索引了。所以，第一原则是，若是经过调整顺序，能够少维护一个索引，那么这个顺序每每就是须要优先考虑采用的。

因此如今你知道了，这段开头的问题里，咱们要为高频请求建立(身份证号，姓名）这个联合索引，并用这个索引支持“根据身份证号查询地址”的需求。

那么，若是既有联合查询，又有基于a、b各自的查询呢？查询条件里面只有b的语句，是没法使用(a,b)这个联合索引的，这时候你不得不维护另一个索引，也就是说你须要同时维护(a,b)、(b) 这两个索引。

这时候，咱们要考虑的原则就是空间了。好比上面这个市民表的状况，name字段是比age字段大的 ，那我就建议你建立一个（name,age)的联合索引和一个(age)的单字段索引。

索引下推

上一段咱们说到知足最左前缀原则的时候，最左前缀能够用于在索引中定位记录。这时，你可能要问，那些不符合最左前缀的部分，会怎么样呢？

咱们仍是以市民表的联合索引（name, age）为例。若是如今有一个需求：检索出表中“名字第一个字是张，并且年龄是10岁的全部男孩”。那么，SQL语句是这么写的：

mysql> select * from tuser where name like '张%' and age=10 and ismale=1;

你已经知道了前缀索引规则，因此这个语句在搜索索引树的时候，只能用 “张”，找到第一个知足条件的记录ID3。固然，这还不错，总比全表扫描要好。

而后呢？

固然是判断其余条件是否知足。

在MySQL 5.6以前，只能从ID3开始一个个回表。到主键索引上找出数据行，再对比字段值。

而MySQL 5.6 引入的索引下推优化（index condition pushdown)， 能够在索引遍历过程当中，对索引中包含的字段先作判断，直接过滤掉不知足条件的记录，减小回表次数。

图3和图4，是这两个过程的执行流程图。

图3 无索引下推执行流程

图4 索引下推执行流程

在图3和4这两个图里面，每个虚线箭头表示回表一次。

图3中，在(name,age)索引里面我特地去掉了age的值，这个过程InnoDB并不会去看age的值，只是按顺序把“name第一个字是’张’”的记录一条条取出来回表。所以，须要回表4次。

图4跟图3的区别是，InnoDB在(name,age)索引内部就判断了age是否等于10，对于不等于10的记录，直接判断并跳过。在咱们的这个例子中，只须要对ID四、ID5这两条记录回表取数据判断，就只须要回表2次。

小结

今天这篇文章，我和你继续讨论了数据库索引的概念，包括了覆盖索引、前缀索引、索引下推。你能够看到，在知足语句需求的状况下， 尽可能少地访问资源是数据库设计的重要原则之一。咱们在使用数据库的时候，尤为是在设计表结构时，也要以减小资源消耗做为目标。

接下来我给你留下一个问题吧。

实际上主键索引也是可使用多个字段的。DBA小吕在入职新公司的时候，就发现本身接手维护的库里面，有这么一个表，表结构定义相似这样的：

CREATE TABLE `geek` (
`a` int(11) NOT NULL,
`b` int(11) NOT NULL,
`c` int(11) NOT NULL,
`d` int(11) NOT NULL,
PRIMARY KEY (`a`,`b`),
KEY `c` (`c`),
KEY `ca` (`c`,`a`),
KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;

公司的同事告诉他说，因为历史缘由，这个表须要a、b作联合主键，这个小吕理解了。

可是，学过本章内容的小吕又纳闷了，既然主键包含了a、b这两个字段，那意味着单独在字段c上建立一个索引，就已经包含了三个字段了呀，为何要建立“ca”“cb”这两个索引？

同事告诉他，是由于他们的业务里面有这样的两种语句：

select * from geek where c=N order by a limit 1;
select * from geek where c=N order by b limit 1;

我给你的问题是，这位同事的解释对吗，为了这两个查询模式，这两个索引是否都是必须的？为何呢？

你能够把你的思考和观点写在留言区里，我会在下一篇文章的末尾和你讨论这个问题。感谢你的收听，也欢迎你把这篇文章分享给更多的朋友一块儿阅读。

上期问题时间

上期的问题是，经过两个alter 语句重建索引k，以及经过两个alter语句重建主键索引是否合理。

在评论区，有同窗问到为何要重建索引。咱们文章里面有提到，索引可能由于删除，或者页分裂等缘由，致使数据页有空洞，重建索引的过程会建立一个新的索引，把数据按顺序插入，这样页面的利用率最高，也就是索引更紧凑、更省空间。

这道题目，我给你的“参考答案”是：

重建索引k的作法是合理的，能够达到省空间的目的。可是，重建主键的过程不合理。不管是删除主键仍是建立主键，都会将整个表重建。因此连着执行这两个语句的话，第一个语句就白作了。这两个语句，你能够用这个语句代替 ： alter table T engine=InnoDB。在专栏的第12篇文章《为何表数据删掉一半，表文件大小不变？》中，我会和你分析这条语句的执行流程。