mysql覆盖索引怎么用,mysql什么是索引覆盖

Mysql 索引覆盖及回表查询

在innoDB中，有两大索引类，分别是

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名申请、雅安服务器托管、营销软件、网站建设、岗巴网站维护、网站推广。

执行上述语句，执行过程如下图

从图中，我们可以看出，扫了两个索引树

（1）先从普通索引name找到lisi

（2）再根据主键值9，再在聚集索引中找到行记录。

这就是回表查询，先在普通索引中找到主键值，再在聚集索引中找到行记录。

很显然，在一棵索引树上就能获取SQL所需的所有列数据的，就是索引覆盖。

如下语句

很显然，我们可以直接在name索引上直接找到id,name，不用再去回表。

而且我们通过explain的extra属性也能观察到

像我们开头的SQL语句

我们只需要在name索引中再加个sex，name(name,sex)，这样变成了联合索引，也是索引覆盖。

mysql优化：覆盖索引（延迟关联）

我们都知道InnoDB采用的B+ tree来实现索引的，索引又分为主键索引(聚簇索引)和普通索引(二级索引)。

那么我们就来看下基于主键索引和普通索引的查询有什么区别？

举个栗子：

可以看出我们有一个普通索引k，那么两颗B+树的示意图如下：

[图片上传失败...(image-9b05f7-1597911217600)]

（注：图来自极客时间专栏）

当我们查询** select * from T where k=5 其实会先到k那个索引树上查询k = 5，然后找到对应的id为500，最后回表到主键索引的索引树找返回所需数据。

如果我们查询 select id from T where k=5 **则不需要回表就直接返回。

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

概念如上，这里我们还是用例子来说明：

/pre

[图片上传失败...(image-20977-1597911217600)]

（注：图来自极客时间专栏）

现在，我们一起来看看这条SQL查询语句的执行流程： select * from T where k between 3 and 5

在这个过程中，回到主键索引树搜索的过程，我们称为回表。可以看到，这个查询过程读了k索引树的3条记录（步骤1、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。

上面介绍了那么多其实是在为延迟关联做铺垫，这里直接续上我们本次慢查询的sql：

我们都知道在做分页时会用到Limit关键字去筛选所需数据，limit接受1个或者2个参数，接受两个参数时第一个参数表示偏移量，即从哪一行开始取数据，第二个参数表示要取的行数。如果只有一个参数，相当于偏移量为0。

当偏移量很大时，如limit 100000,10 取第100001-100010条记录，mysql会取出100010条记录然后将前100000条记录丢弃，这无疑是一种巨大的性能浪费。

当有这种写法时，我们可以采用延迟关联来进行优化，重点关注： SELECT id FROM qa_question WHERE expert_id = 69 AND STATUS = 30 ORDER BY over_time DESC LIMIT 0, 10 ，这里其实利用了索引覆盖，where条件后的expert_id 是有添加索引的，这里查询id 可以避免回表，大大提升效率。

工作中会遇到各种各样的问题，对于一个研发来说最重要的是能够从这些问题中学到什么。好久没有写博客了，究其原因还是自己变得懒惰了。 (￣ェ￣;)

最后以《高性能Mysql》中的一段话结束：

浅聊 MySQL索引覆盖

尽量使用覆盖索引，减少select *。那么什么是覆盖索引呢？覆盖索引是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到。

现在有一张用户表tb_user;

索引情况：

接下来，我们来看一组SQL的执行计划，看看执行计划的差别，然后再来具体做一个解析。

Using where; Using Index：查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据

Using index condition：查找使用了索引，但是需要回表查询数据

因为，在tb_user表中有一个联合索引 idx_user_pro_age_sta，该索引关联了三个字段 profession、age、status，而这个索引也是一个二级索引，所以叶子节点下面挂的是这一行的主键id。所以当我们查询返回的数据在 id、profession、age、status 之中，则直接走二级索引直接返回数据了。如果超出这个范围，就需要拿到主键id，再去扫描聚集索引，再获取额外的数据了，这个过程就是回表。而我们如果一直使用select * 查询返回所有字段值，很容易就会造成回表查询（除非是根据主键查询，此时只会扫描聚集索引）。

为了大家更清楚的理解，什么是覆盖索引，什么是回表查询，我们一起再来看下面的这组SQL的执行过程。

id是主键，是一个聚集索引。 name字段建立了普通索引，是一个二级索引（辅助索引）。

B. 执行SQL : select * from tb_user where id = 2;

根据id查询，直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。

C. 执行SQL：selet id,name from tb_user where name = 'Arm';

虽然是根据name字段查询，查询二级索引，但是由于查询返回在字段为 id，name，在name的二级索引中，这两个值都是可以直接获取到的，因为覆盖索引，所以不需要回表查询，性能高。

D. 执行SQL：selet id,name,gender from tb_user where name = 'Arm';

由于在name的二级索引中，不包含gender，所以，需要两次索引扫描，也就是需要回表查询，性能相对较差一点。

MySql 索引（聚集索引，辅助索引，联合索引，覆盖索引..）

引入一个面试问题:

看完以下以后再回顾，会发现迎刃而解

Mysql 可以为每一张表设置存储引擎这里我们只说 InnoDB 存储引擎.

由于实际情况，数据页只能按照一棵 B+树进行排序，因此每张表只能拥有一个聚集索引（即主键）。

栗子：

每个叶子节点的索引行中包含了一个书签（bookmark）. 该书签是用来告诉 InnoDB存储引擎哪里可以找到该索引对应的数据行或者说行数据！由于InnoDB存储引擎表，是按照主键来构建的，所以，该书签内其实包含或者说指向了数据行所对应的聚集索引键

也就是说辅助索引的叶结点保存了指向对应数据的聚集索引，可以通过该聚集索引找到对应的数据行

辅助索引的存在并不影响数据在聚集索引中的组织，因为每张表上可以有多个辅助索引。

当通过辅助索引来寻找数据时，InnoDB 存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引(聚集索引)的主键，然后再通过聚集索引找到一个完整的数据行。

例如：

聚集索引辅助索引关系:

：又叫做组合索引，辅助索引的一种，和普通创建索引的方式一样，不同的是可以同时添加多列来作为索引项;

从本质上来说，联合索引也是一课B+树

个人理解：所谓最左原则，是因为存储引擎构建组合索引时是根据最左边的那一列索引项进行排序的，所以使用组合索引，必须满足条件中必须存在最左边那一列的索引项，这样才可以找到对应的索引，继而去寻找对应的数据

：又叫做索引覆盖，InnoDB中支持覆盖索引，即从辅助索引中就可以得到查询的记录，而不需要查询聚集索引中的记录。

比如这里没有根据最左原则使用组合索引，但是优化器依然进行选择

共勉，欢迎指导谢谢~

「Mysql索引原理（七）」覆盖索引

通常大家都会根据查询的WHERE条件来创建合适的索引，不过这只是索引优化的一个方面。设计优秀的索引应该考虑到整个查询，而不单单是WHERE条件部分。索引确实是一种查找数据的高效方式，但是MySQL也可以使用索引来直接获取列的数据，这样就不再需要读取数据行。如果索引的叶子节点中已经包含要查询的数据，那么还有什么必要再回到表中查询呢？如果一个索引覆盖所有需要查询的字段的值，我们就称之为“覆盖索引”。

覆盖索引是非常有用的工具，能够极大地提高性能：

在所有这些场景中，在索引中满足查询的成本一般比查询行要小得多。

不是所有类型的索引都可以成为覆盖索引。覆盖索引必须要存储索引列的值，而哈希索引、空间索引和全文索引都不存储索引列的值，所以MySQL只能使用B+Tree索引所覆盖索引。另外，不同的存储引擎实现覆盖索引的方式也不同，而且不是所有的引擎都支持覆盖索引。

当发起一个呗索引覆盖的查询是，在EXPLAIN的Extra列可以看到“Using index”的信息。

如： explain select col1 from layout_test where col2=99

索引覆盖查询还有很多陷阱可能会导致无法实现优化。MySQL查询优化器会在执行查询前判断是否有一个索引能进行覆盖。假设索引覆盖了wehre条件中的字段，但不是整个查询涉及的字段。mysql5.5和更早的版本也总是会回表获取数据行，尽管并不需要这一行且最终会被过滤掉。

如： EXPLAIN select * from people where last_name='Allen' and first_name like '%Kim%'

这里索引无法覆盖该查询，有两个原因：

这条语句只检索1行，而之前的 like '%Kim%'要检索3行。

也有办法解决上面所说的两个问题，需要重写查询并巧妙设计索引。

这种方式叫做延迟关联，因为延迟了对列的访问。在查询第一个阶段MySQL可以使用覆盖索引，因为索引包含了主键id的值，不需要做二次查找。

在FROM子句的子查询中找到匹配的id，然后根据这些id值在外层查询匹配获取需要的所有列值。虽然无法使用索引覆盖整个查询，但总算比完全无法利用索引覆盖的好吧。

数据量大了怎么办？

这样优化的效果取决于WHERE条件匹配返回的行数。假设这个people表有100万行，我们看一下上面两个查询在三个不同的数据集上的表现，每个数据集都包含100万行。

实例1中，查询返回了一个很大的结果集，因此看不到优化的效果。大部分时间都花在读取和发送数据上了。

实例2中，经过索引过滤，尤其是第二个条件过滤后只返回了很少的结果集，优化的效果非常明显：在这个数据及上性能提高了很多，优化后的查询效率主要得益于只需读取40行完整数据行，而不是原查询中需要的30000行。

实例3中，子查询效率反而下降。因为索引过滤时符合第一个条件的结果集已经很小了，所以子查询带来的成本反而比从表中直接提取完整行更高。

在大多数存储引擎中，覆盖索引只能覆盖那些只访问索引中部分列的查询。不过，可以更进一步优化InnoDB。回想一下，InnoDB的二级索引的叶子节点都包含了主键的值，这意味着InnoDB的二级索引可以有效地利用这些额外的主键列来覆盖查询。

例如，people表中last_name字段有一个二级索引，虽然该索引的列不包括主键id，但也能够用于对id做覆盖查询：

select id,last_name from people where last_name='hua'