文章目录
- 1 回表
- 2 最左匹配原则
- 3 索引覆盖
- 4 索引下推
1 回表
这先要从InnoDB的索引实现说起，InnoDB有两大类索引：
聚集索引(clustered index)
普通索引(secondary index)
InnoDB聚集索引和普通索引有什么差异？
InnoDB聚集索引的叶子节点存储行记录，因此， InnoDB必须要有，且只有一个聚集索引：
（1）如果表定义了PK，则PK就是聚集索引；
（2）如果表没有定义PK，则第一个not NULL unique列是聚集索引；
（3）否则，InnoDB会创建一个隐藏的row-id作为聚集索引；
画外音：所以PK查询非常快，直接定位行记录。
InnoDB普通索引的叶子节点存储主键值。
画外音：注意，不是存储行记录头指针，MyISAM的索引叶子节点存储记录指针。
举个栗子，不妨设有表：
t(id PK, name KEY, sex, flag);
画外音：id是聚集索引，name是普通索引。
表中有四条记录：
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
两个B+树索引分别如上图：
（1）id为PK，聚集索引，叶子节点存储行记录；
（2）name为KEY，普通索引，叶子节点存储PK值，即id；
既然从普通索引无法直接定位行记录，那普通索引的查询过程是怎么样的呢？
通常情况下，需要扫码两遍索引树。
例如：
select * from t where name=‘lisi’;
是如何执行的呢？
如粉红色路径，需要扫码两遍索引树：
（1）先通过普通索引定位到主键值id=5；
（2）在通过聚集索引定位到行记录；
这就是所谓的回表查询，先定位主键值，再定位行记录，它的性能较扫一遍索引树更低。
2 最左匹配原则
首先建立一个组合索引：index（province，city，street）
查询条件 | 索引是否生效 |
where province=? and city=? and street=? | 生效 |
where city=? and province=? and street=? | 特殊情况，mysql优化器自动处理为索引顺序，生效 |
where province=? | 生效 |
where province=? and city=? | 生效 |
where province=? and street=? | 生效 |
where city=? and street=? | 不生效 |
where city=? | 不生效 |
where street=? | 不生效 |
可以看到，只要满足最左前缀(除了mysql优化处理的情况)，就可以利用索引来加速检索。这个最左前缀可以是联合索引的最左 N 个字段，也可以是字符串索引的最左 M 个字符。
3 索引覆盖
一句话概括：只需要在一棵索引树上就能获取SQL所需的所有列数据，无需回表，速度更快。
常见的方法是：将被查询的字段，建立到联合索引里去。
仍是《迅猛定位低效SQL？》中的例子：
create table user (
id int primary key,
name varchar(20),
sex varchar(5),
index(name)
)engine=innodb;
第一个SQL语句：
select id,name from user where name=‘shenjian’;
能够命中name索引，索引叶子节点存储了主键id，通过name的索引树即可获取id和name，无需回表，符合索引覆盖，效率较高。
画外音，Extra：Using index。
第二个SQL语句：
select id,name,sex* from user where name=‘shenjian’;*
能够命中name索引，索引叶子节点存储了主键id，但sex字段必须回表查询才能获取到，不符合索引覆盖，需要再次通过id值扫码聚集索引获取sex字段，效率会降低。
如果把(name)单列索引升级为联合索引(name, sex)就不同了。
create table user (
id int primary key,
name varchar(20),
sex varchar(5),
index(name, sex)
)engine=innodb;
可以看到：
select id,name … where name=‘shenjian’;
select id,name,sex* … where name=‘shenjian’;*
都能够命中索引覆盖，无需回表。
哪些场景可以利用索引覆盖来优化SQL？场景1：全表count查询优化
原表为：
user(PK id, name, sex)；
直接：
select count(name) from user;
不能利用索引覆盖。
添加索引：
alter table user add key(name);
就能够利用索引覆盖提效。
场景2：列查询回表优化
select id,name,sex … where name=‘shenjian’;
这个例子不再赘述，将单列索引(name)升级为联合索引(name, sex)，即可避免回表。
场景3：分页查询
select id,name,sex … order by name limit 500,100;
将单列索引(name)升级为联合索引(name, sex)，也可以避免回表。
4 索引下推
- 索引下推（index condition pushdown ）简称ICP，在Mysql5.6的版本上推出，用于优化查询。
- 在不使用ICP的情况下，使用非主键索引（又叫普通索引或者二级索引）进行查询时，存储引擎通过索引检索到数据，然后返回给MySQL服务器，服务器然后判断数据是否符合条件 。
- 在使用ICP的情况下，如果存在某些被索引的列的判断条件时，MySQL服务器将这一部分判断条件传递给存储引擎，然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件，只有当索引符合条件时才会将数据检索出来返回给MySQL服务器 。
- 索引条件下推优化可以减少存储引擎查询基础表的次数，也可以减少MySQL服务器从存储引擎接收数据的次数。
在开始之前先准备一张用户表(user)，其中主要几个字段有：id、name、age、address。建立联合索引（name，age）。
假设有一个需求，要求匹配姓名第一个为陈的所有用户，sql语句如下：
SELECT * from user where name like ‘陈%’
根据 “最佳左前缀” 的原则，这里使用了联合索引（name，age）进行了查询，性能要比全表扫描肯定要高。
问题来了，如果有其他的条件呢？假设又有一个需求，要求匹配姓名第一个字为陈，年龄为20岁的用户，此时的sql语句如下：
SELECT * from user where name like ‘陈%’ and age=20
这条sql语句应该如何执行呢？下面对Mysql5.6之前版本和之后版本进行分析。
Mysql5.6之前的版本
- 5.6之前的版本是没有索引下推这个优化的，因此执行的过程如下图：
- 会忽略age这个字段，直接通过name进行查询，在(name,age)这课树上查找到了两个结果，id分别为2,1，然后拿着取到的id值一次次的回表查询，因此这个过程需要回表两次。
Mysql5.6及之后版本
- 5.6版本添加了索引下推这个优化，执行的过程如下图：
- InnoDB并没有忽略age这个字段，而是在索引内部就判断了age是否等于20，对于不等于20的记录直接跳过，因此在(name,age)这棵索引树中只匹配到了一个记录，此时拿着这个id去主键索引树中回表查询全部数据，这个过程只需要回表一次。
总结
- 索引下推在非主键索引上的优化，可以有效减少回表的次数，大大提升了查询的效率。
