首页 > 其他分享> 文章详细

什么是覆盖索引

2022-09-04 10:30:45 阅读：145 来源： 互联网

标签：聚集 name 覆盖什么 id 回表索引主键

前言

在了解索引覆盖前,我们先来看下,聚集索引，非聚集索引，回表等概念.

什么是聚集索引

聚集索引是按照每张表的主键构造一颗B+树，同时叶子节点中存放的就是整张表的行记录数据，也将聚集索引的叶子节点称为数据页。这个特性决定了索引组织表中数据也是索引的一部分

主键被定义了，那么这个主键作为聚集索引
主键没有被定义，那么该表的第一个唯一非空索引被作为聚集索引
主键没有定义,同时也没有合适的唯一索引，那么innodb内部会生成一个隐藏的主键作为聚集索引，这个隐藏的主键是一个6个字节的列，该列的值会随着数据的插入自增

什么是非聚集索引

在聚集索引之上创建的索引称之为非聚集索引，非聚集索引访问数据总是需要二次查找。叶子节点存储的不是行的物理位置，而是主键值。通过非聚集索引首先找到的是主键值，再通过主键值找到数据行的数据页，再通过数据页中的Page Directory找到数据行。

叶子节点并不包含行记录的全部数据，叶子节点除了包含键值外，还包含了相应行数据的聚簇索引键。
不影响数据在聚簇索引中的组织，所以一张表可以有多个非聚集索引

什么是回表

现在有这样一张表:

CREATE TABLE `user`  (
  `id` int(11) NOT NULL,
  `name` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL,
  `sex` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL,
  `flag` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `idx_name`(`name`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin ROW_FORMAT = Compact;

INSERT INTO `user` VALUES (1, 'shenjian', 'm', 'A');
INSERT INTO `user` VALUES (3, 'zhangsan', 'm', 'A');
INSERT INTO `user` VALUES (5, 'lisi', 'm', 'A');
INSERT INTO `user` VALUES (9, 'wangwu', 'f', 'B');

两个 B+ 树索引分别如图：

id 为主键，聚集索引，叶子节点存储行记录；
name 为索引，普通索引，叶子节点存储主键值，即 id

既然从普通索引无法直接定位行记录，那普通索引的查询过程是怎么样的呢？
通常情况下，需要扫码两遍索引树。
例如:

SELECT * FROM `user` WHERE name='lisi';

是如何执行的呢？

如粉红色路径，需要扫码两遍索引树：
先通过普通索引定位到主键值 id=5,在通过聚集索引定位到行记录
这就是所谓的回表查询，先定位主键值，再定位行记录，它的性能较扫一遍索引树更低

覆盖索引

如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为“覆盖索引”
我们知道 InnoDB 存储引擎中，如果不是主键索引，叶子节点存储的是主键+列值。最终还是要“回表”，也就是要通过主键再查找一次，这样就会比较慢。覆盖索引就是把要查询出的列和索引是对应的，不做回表操作

如何实现索引覆盖？

常见的方法是：将被查询的字段，建立到联合索引里去（或者说查询的字段都已经建立了索引）。

还是用上边的例子 user 表

第一个SQL语句：

SELECT id, name FROM user WHERE name='shenjian';

能够命中 name 索引，索引叶子节点存储了主键 id，通过 name 的索引树即可获取 id 和 name，无需回表，符合索引覆盖，效率较高。
第二个SQL语句：

SELECT id, name, sex FROM user WHERE name='shenjian';

能够命中 name 索引，索引叶子节点存储了主键 id，但 sex 字段必须回表查询才能获取到，不符合索引覆盖，需要再次通过 id 值扫码聚集索引获取 sex 字段，效率会降低。
如果把 (name) 单列索引升级为联合索引 (name, sex) 就不同了：
再次执行，第二个SQL语句：

SELECT id, name, sex FROM user WHERE name='shenjian';

能够命中联合索引，索引叶子节点存储了主键 id，通过联合索引的索引树即可获取 name 和 sex，无需回表，符合索引覆盖，效率较高。

回表优化

现在有一张订单信息表, sn字段建立了非聚集索引,有一条查询订单信息的sql：

SELECT o1.* FROM orders WHERE sn='XD12345678' LIMIT 10000,10

因为数据表是 InnoDB，根据 InnoDB 索引的结构，查询过程为：

通过二级索引查到主键值（找出所有 sn='XD12345678' 的 id)。
再根据查到的主键值通过主键索引找到相应的数据块（根据 id 找出对应的数据块内容）。
根据 offset 的值，查询 10010 次主键索引的数据，最后将之前的 10000 条丢弃，取出最后 10 条
因为我们要查询 o1.*，前边丢弃的 10000 条数据，经过大量回表操作，造成了大量的 I/O 消耗，浪费了很多性能，导致查询时间变得很长。
优化sql:

SELECT o1.* FROM orders o1
INNER JOIN (SELECT id FROM orders WHERE sn='XD12345678' LIMIT 10000,10) o2
ON o1.id = o2.id;

而这样的写法在 o2 分页查询时根本无需回表只查询 id，最后再做一个内连接根据主键取出数据，虽然增加了 SQL 语句的复杂度，但是性能非常好。

标签：聚集,name,覆盖,什么,id,回表,索引,主键
来源： https://www.cnblogs.com/susuww/p/16654414.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9