回表与覆盖索引，索引下推

Posted 2023-04-18

参考技术A

通俗的讲就是，如果索引的列在 select 所需获得的列中（因为在 mysql 中索引是根据索引列的值进行排序的，所以索引节点中存在该列中的部分值）或者根据一次索引查询就能获得记录就不需要回表，如果 select 所需获得列中有大量的非索引列，索引就需要到表中找到相应的列的信息，这就叫回表。

InnoDB聚集索引的叶子节点存储行记录，因此， InnoDB必须要有，且只有一个聚集索引：

（1）如果表定义了主键，则PK就是聚集索引；
（2）如果表没有定义主键，则第一个非空唯一索引（not NULL unique）列是聚集索引；
（3）否则，InnoDB会创建一个隐藏的row-id作为聚集索引；

先创建一张表，sql 语句如下：

然后，我们再执行下面的 SQL 语句，插入几条测试数据。

假设，现在我们要查询出 id 为 2 的数据。那么执行 select * from xttblog where ID = 2; 这条 SQL 语句就不需要回表。原因是根据主键的查询方式，则只需要搜索 ID 这棵 B+ 树。主键是唯一的，根据这个唯一的索引，MySQL 就能确定搜索的记录。

但当我们使用 k 这个索引来查询 k = 2 的记录时就要用到回表。select * from xttblog where k = 2; 原因是通过 k 这个普通索引查询方式，则需要先搜索 k 索引树，然后得到主键 ID 的值为 1，再到 ID 索引树搜索一次。这个过程虽然用了索引，但实际上底层进行了两次索引查询，这个过程就称为回表。

也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。

我这里表里的数据量比较少，如果数据量大的话，你能很明显的看出两次查询所用的时间，很明显使用主键查询效率更高。

更多如下图：

（1）先通过普通索引定位到主键值id=5；
（2）在通过聚集索引定位到行记录；
这就是所谓的回表查询，先定位主键值，再定位行记录，它的性能较扫一遍索引树更低。

使用聚集索引（主键或第一个唯一索引）就不会回表，普通索引就会回表。

只需要在一棵索引树上就能获取SQL所需的所有列数据，无需回表，速度更快。

explain的输出结果Extra字段为Using index时，能够触发索引覆盖。

例子

第一个sql：
select id,name from user where name=\'shenjian\';

Extra：Using index。

第二个sql：
select id,name,sex from user where name=\'shenjian\';

能够命中name索引， 索引叶子节点存储了主键id，没有储存sex，sex字段必须回表查询才能获取到 ，不符合索引覆盖，需要再次通过id值扫描聚集索引获取sex字段，效率会降低。

Extra：Using index condition。

如果把(name)单列索引升级为联合索引(name, sex)就不同了。

可以看到：

select id,name ... where name=\'shenjian\';
select id,name,sex ... where name=\'shenjian\';
单列索升级为联合索引(name, sex)后，索引叶子节点存储了主键id，name，sex ，都能够命中索引覆盖，无需回表。

画外音，Extra：Using index。

场景1：全表count查询优化

原表为：
user(PK id, name, sex)；

直接：
select count(name) from user;
不能利用索引覆盖。

添加索引：
alter table user add key(name);
就能够利用索引覆盖提效。

场景2：列查询回表优化

这个例子不再赘述，将单列索引(name)升级为联合索引(name, sex)，即可避免回表。

场景3：分页查询

将单列索引(name)升级为联合索引(name, sex)，也可以避免回表。

假设有这么个需求，查询表中“名字第一个字是张，性别男，年龄为10岁的所有记录”。那么，查询语句是这么写的：

根据前面说的“最左前缀原则”，该语句在搜索索引树的时候，只能匹配到名字第一个字是‘张’的记录（即记录ID3），接下来是怎么处理的呢？当然就是从ID3开始，逐个回表，到主键索引上找出相应的记录，再比对age和ismale这两个字段的值是否符合。

但是！MySQL 5.6引入了索引下推优化，可以在索引遍历过程中， 对索引中包含的字段先做判断，过滤掉不符合条件的记录，减少回表字数 。
下面图1、图2分别展示这两种情况。

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

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

如果没有索引下推优化（或称ICP优化），当进行索引查询时， 首先根据索引来查找记录，然后再根据where条件来过滤记录 ；在支持ICP优化后，MySQL会在取出索引的同时， 判断是否可以进行where条件过滤再进行索引查询 ，也就是说提前执行where的部分过滤操作，在某些场景下，可以大大减少回表次数，从而提升整体性能。

​

MySql索引下推知识分享

作者：刘邓忠

Mysql是大家最常用的数据库，下面为大家带来mysql索引下推知识点的分享，以便巩固mysql基础知识，如有错误，还请各位大佬们指正。

1 什么是索引下推

索引下推(Index Condition Pushdown，索引条件下推，简称ICP)，是MySQL5.6版本的新特性，它可以在对联合索引遍历过程中，对索引中包含的所有字段先做判断，过滤掉不符合条件的记录之后再回表，能有效的减少回表次数（目前我们使用的mysql版本较高，一般大家可能感觉这是正常的，但是mysql5.6之前都不是这样实现的，下面会细细道来）。

1.1 适用条件

我们先来了解一下索引下推的使用条件及限制：

• 只支持select。
• 当需要访问全表时，ICP用于range，ref，eq_ref和ref_or_null访问类型。
• ICP可用于InnoDB和MyISAM表，包括分区的InnoDB和MyISAM表。（5.6版本不适用分区表查询，5.7版本后可以用于分区表查询）。
• 对于InnDB引擎只适用于二级索引（也叫辅助索引），因为InnDB的聚簇索引会将整行数据读到InnDB的缓冲区，这样一来索引条件下推的主要目的减少IO次数就失去了意义。因为数据已经在内存中了，不再需要去读取了。
• 在虚拟生成列上创建的辅助索引不支持ICP（注：InnoDB支持虚拟生成列的辅助索引）。
• 使用了子查询的条件无法下推。
• 使用存储过程或函数的条件无法下推（因为因为存储引擎没有调用存储过程或函数的能力）。
• 触发条件无法下推。（有关触发条件的信息，请参阅官方资料：Section 8.2.2.3, “Optimizing Subqueries with the EXISTS Strategy”.。）

1.2 原理介绍

首先，我们大致回顾下mysql的基本架构：

MySQL基本的架构示例图

MySQL服务层主要负责SQL语法解析、生成执行计划等，并调用存储引擎层去执行数据的存储和查询。

索引下推的下推其含义就是指将部分上层（服务层）负责的事情，交给了下层（引擎层）去处理。

在 MySql 5.6 版本之前没有索引下推这个功能，从 5.6 版本后才加上了这个优化项。我们先简单对比一下使用和未使用ICP两种情况下，MySql的查询过程吧。

1)未使用ICP的情况下：

- 存储引擎读取索引记录；

- 根据索引中的主键值，定位并读取完整的行记录；

- 存储引擎把记录交给Server层去检测该记录是否满足WHERE条件。

2)使用ICP的情况下：

- 存储引擎读取索引记录（不是完整的行记录）；

- 判断WHERE条件部分能否用索引中的列来做检查，条件不满足，则处理下一行索引记录；

- 条件满足，使用索引中的主键去定位并读取完整的行记录（就是所谓的回表）；

- 存储引擎把记录交给Server层，Server层检测该记录是否满足WHERE条件的其余部分。

2 具体示例

上面介绍了基本原理，下面使用示例，带大家更直观的进行理解（注：以下示例基于InnoDB存储引擎。）

首先，我们新建一张用户表（jxc_user），设置id为主键索引，并创建联合索引（name, age）。

我们先看一下该表主键索引的大致结构示例：

主键索引结构示例图

然后我们再看一下该表联合索引的大致结构示例：

联合索引结构示例图

如果现在有一个需求，要求检索出表中名字第一个字是张，而且年龄等于10岁的所有用户。示例SQL语句如下：

select id,name,age,tel,addr from jxc_user where name like 张% and age=10;

根据索引最左匹配原则，上面这个sql语句在查索引树的时候，只能用“张”，查到第一个满足条件的记录：id为1。
那接下来我们具体看一下 使用与未使用ICP的情况。

2.1 未使用ICP的情况

在MySQL 5.6之前，存储引擎根据联合索引先找到name like ‘张%’ 的主键id（1、4），再逐一进行回表扫描，去聚簇索引找到完整的行记录，返回server层，server层拿到数据后，再根据条件age=10对拿到的数据进行筛选。大致的示意图如下：

从上图，可以看到需要回表两次，存储引擎并不会去按照age=10进行过滤，相当于联合索引的另一个字段age在存储引擎层没有发挥作用，比较浪费。

2.2 使用ICP的情况

而MySQL 5.6 以后， 存储引擎会根据（name，age）联合索引，找到name like ‘张%’，由于联合索引中包含age列，所以存储引擎直接再联合索引里按照条件age=10进行过滤，然后根据过滤后的数据再依次进行回表扫描。大致的示意图如下：

从上图，可以看到只是id=1的数据，回表了一次。

除此之外我们还可以看一下执行计划，看到Extra一列里Using index condition，就是用到了索引下推。

3 控制参数

Mysql索引下推功能默认是开启的，可以用系统参数optimizer_switch来控制是否开启。
查看状态命令：
select @​​@optimizer_switch​​;

关闭命令：set optimizer_switch=”index_condition_pushdown=off”;
开启命令：set optimizer_switch=”index_condition_pushdown=on”;

4 总结

回表操作：当所要查找的字段不在非主键索引树上时，需要通过叶子节点的主键值去主键索引上获取对应的行数据，这个过程称为回表操作。
索引下推：索引下推主要是减少了不必要的回表操作。对于查找出来的数据，先过滤掉不符合条件的，其余的再去主键索引树上查找。

5 参考文献

• ​​https://dev.mysql.com/doc/refman/5.6/en/index-condition-pushdown-optimization.html​​
• ​​http://mysql.taobao.org/monthly/2015/12/08/​​