MySQL 回表[亲测有效]

MySQL 回表[亲测有效]MySQL 回表 五花马,千金裘,呼儿将出换美酒,与尔同销万古愁。 一、简述 回表,顾名思义就是回到表中,也就是先通过普通索引扫描出数据所在的行,再通过行主键ID 取出索引中未包含的数据。所

MySQL 回表

MySQL 回表

 

    五花马,千金裘,呼儿将出换美酒,与尔同销万古愁。

 

一、简述

回表,顾名思义就是回到表中,也就是先通过普通索引扫描出数据所在的行,再通过行主键ID 取出索引中未包含的数据。所以回表的产生也是需要一定条件的,如果一次索引查询就能获得所有的select 记录就不需要回表,如果select 所需获得列中有其他的非索引列,就会发生回表动作。即基于非主键索引的查询需要多扫描一棵索引树

二、InnoDB 引擎有两大类索引

要弄明白回表,首先得了解 InnoDB 两大索引,即聚集索引 (clustered index)和普通索引(secondary index)。

聚集索引 clustered index

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

  • 如果表定义了主键,则Primary Key 就是聚集索引;
  • 如果表没有定义主键,则第一个非空唯一索引(Not NULL Unique)列是聚集索引;
  • 否则,InnoDB会创建一个隐藏的row-id作为聚集索引;

普通索引(secondary index

普通索引也叫二级索引,除聚簇索引外的索引都是普通索引,即非聚簇索引。

InnoDB的普通索引叶子节点存储的是主键(聚簇索引)的值,而MyISAM的普通索引存储的是记录指针。

三、回表示例

数据准备

先创建一张表  t_back_to_table ,表中id 为主键索引即聚簇索引,drinker_id为普通索引。

CREATE TABLE t_back_to_table (

id INT PRIMARY KEY,

drinker_id INT NOT NULL,

drinker_name VARCHAR ( 15 ) NOT NULL,

drinker_feature VARCHAR ( 15 ) NOT NULL,

INDEX ( drinker_id )

) ENGINE = INNODB; 

再执行下面的 SQL 语句,插入四条测试数据。

INSERT INTO t_back_to_table ( id, drinker_id, drinker_name, drinker_feature )

VALUES

( 1, 2, "广西-玉林", "喝到天亮" ),

( 2, 1, "广西-河池", "白酒三斤半啤酒随便灌" ),

( 3, 3, "广西-贵港", "喝到晚上" ),

( 4, 4, "广西-柳州", "喝酒不吃饭" );

MySQL 回表[亲测有效]

NO回表case 

使用主键索引id查询出id 3 的数据。

EXPLAIN SELECT * FROM t_back_to_table WHERE id = 3;

执行 EXPLAIN SELECT * FROM t_back_to_table WHERE id = 3,这条 SQL 语句就不需要回表。

因为是根据主键的查询方式,则只需要搜索 ID 这棵 B+ ,树上的叶子节点存储了行记录,根据这个唯一的索引,MySQL 就能确定搜索的记录。

回表case 

使用 drinker_id 这个索引来查询 drinker_id = 3 的记录时就会涉及到回表。

SELECT * FROM t_back_to_table WHERE drinker_id = 3;

因为通过 drinker_id 这个普通索引查询方式,则需要先搜索 drinker_id 索引树(该索引树上记录着主键ID的值),然后得到主键 ID 的值为 3,再到 ID 索引树搜索一次。这个过程虽然用了索引,但实际上底层进行了两次索引查询,这个过程就称为回表。

回表小结

  • 对比发现,基于非主键索引的查询需要多扫描一棵索引树,先定位主键值,再定位行记录,它的性能较扫一遍索引树更低。
  • 在应用中应该尽量使用主键查询,这里表中就四条数据,如果数据量大的话,就可以明显的看出使用主键查询效率更高。
  • 使用聚集索引(主键或第一个唯一索引)就不会回表,普通索引就会回表。

四、索引存储结构

InnoDB 引擎的聚集索引和普通索引都是B+Tree 存储结构只有叶子节点存储数据

  • 新的B+树结构没有在所有的节点里存储记录数据,而是只在最下层的叶子节点存储,上层的所有非叶子节点只存放索引信息,这样的结构可以让单个节点存放更多索引值,增大Degree 的值,提高命中目标记录的几率。
  • 这种结构会在上层非叶子节点存储一部分冗余数据,但是这样的缺点都是可以容忍的,因为冗余的都是索引数据,不会对内存造成大的负担。

聚簇索引

id 是主键,所以是聚簇索引,其叶子节点存储的是对应行记录的数据

聚簇索引存储结构

MySQL 回表[亲测有效]

如果查询条件为主键(聚簇索引),则只需扫描一次B+树即可通过聚簇索引定位到要查找的行记录数据。

如:

SELECT * FROM t_back_to_table WHERE id = 1;

查找过程:

聚簇索引查找过程 
MySQL 回表[亲测有效]

普通索引

drinker_id 是普通索引(二级索引),非聚簇索引叶子节点存储的是聚簇索引的值,即主键ID的值

普通索引存储结构

MySQL 回表[亲测有效]

如果查询条件为普通索引(非聚簇索引),需要扫描两次B+树

  • 第一次扫描通过普通索引定位到聚簇索引的值
  • 第二次扫描通过第一次扫描获得的聚簇索引的值定位到要查找的行记录数据。

如:

SELECT * FROM t_back_to_table WHERE drinker_id = 1;

(1)第一步,先通过普通索引定位到主键值id=1

2第二步,回表查询,再通过定位到的主键值即聚集索引定位到行记录数据。

普通索引查找过程

MySQL 回表[亲测有效]

五、如何防止回表

既然我们知道了有回表这么回事,肯定就要尽可能去防微杜渐。最常见的防止回表手段就是索引覆盖,通过索引打败索引。

索引覆盖

为什么可以使用索引打败索引防止回表呢?因为其只需要在一棵索引树上就能获取SQL所需的所有列数据,无需回表查询

例如:SELECT * FROM t_back_to_table WHERE drinker_id = 1;

如何实现覆盖索引?

常见的方法是将被查询的字段,建立到联合索引中。

解释性SQL的explain的输出结果Extra字段为Using index时表示触发了索引覆盖。

No覆盖索引case1

继续使用之前创建的 t_back_to_table 表,通过普通索引drinker_id 查询id 和 drinker_id 列。

EXPLAIN SELECT id, drinker_id FROM t_back_to_table WHERE drinker_id = 1;

MySQL 回表[亲测有效]

explain分析:为什么没有创建覆盖索引Extra字段仍为Using index,因为drinker_id是普通索引,使用到了drinker_id索引,在上面有提到普通索引的叶子节点保存了聚簇索引的值所以通过一次扫描B+树即可查询到相应的结果,这样就实现了隐形的覆盖索引即没有人为的建立联合索引。(drinker_id索引上包含了主键索引的值

No覆盖索引case2

继续使用之前创建的 t_back_to_table 表,通过普通索引drinker_id查询 iddrinker_iddrinker_feature列数据。

EXPLAIN SELECT id, drinker_id, drinker_feature FROM t_back_to_table WHERE drinker_id = 1;

MySQL 回表[亲测有效]

explain分析:drinker_id是普通索引其叶子节点上仅包含主键索引的值,而 drinker_feature 不在索引树上,所以通过drinker_id 索引在查询到id和drinker_id的值后,需要根据主键id 进行回表查询,得到 drinker_feature 的值。此时的Extra列的NULL表示进行了回表查询。

覆盖索引case

为了实现索引覆盖,需要建组合索引 idx_drinker_id_drinker_feature(drinker_id,drinker_feature)

#删除索引 drinker_id

DROP INDEX drinker_id ON t_back_to_table;

#建立组合索引

CREATE INDEX idx_drinker_id_drinker_feature on t_back_to_table(`drinker_id`,`drinker_feature`);

继续使用之前创建的 t_back_to_table 表,通过覆盖索引 idx_drinker_id_drinker_feature 查询 iddrinker_iddrinker_feature列数据。

EXPLAIN SELECT id, drinker_id, drinker_feature FROM t_back_to_table WHERE drinker_id = 1;

MySQL 回表[亲测有效]

explain分析:此时字段drinker_iddrinker_feature是组合索引idx_drinker_id_drinker_feature,查询的字段id、drinker_iddrinker_feature的值刚刚都在索引树上,只需扫描一次组合索引B+树即可,这就是实现了索引覆盖,此时的Extra字段为Using index表示使用了索引覆盖。

六、索引覆盖优化SQL场景

适合使用索引覆盖来优化SQL的场景如全表count查询、列查询回表和分页查询等。

全表count查询优化

#首先删除 t_back_to_table 表中的组合索引

DROP INDEX idx_drinker_id_drinker_feature ON t_back_to_table;

EXPLAIN SELECT COUNT(drinker_id) FROM t_back_to_table

MySQL 回表[亲测有效]

explain分析:此时的Extra字段为Null 表示没有使用索引覆盖。

使用索引覆盖优化,创建drinker_id字段索引。

#创建 drinker_id 字段索引

CREATE INDEX idx_drinker_id on t_back_to_table(drinker_id);

EXPLAIN SELECT COUNT(drinker_id) FROM t_back_to_table

MySQL 回表[亲测有效]

explain分析:此时的Extra字段为Using index表示使用了索引覆盖。

列查询回表优化

前文在描述索引覆盖使用的例子就是列查询回表优化。

例如:

SELECT id, drinker_id, drinker_feature FROM t_back_to_table WHERE drinker_id = 1;

使用索引覆盖:建组合索引 idx_drinker_id_drinker_feature on t_back_to_table(`drinker_id`,`drinker_feature`)即可

分页查询优化

#首先删除 t_back_to_table 表中的索引 idx_drinker_id

DROP INDEX idx_drinker_id ON t_back_to_table;

EXPLAIN SELECT id, drinker_id, drinker_name, drinker_feature FROM t_back_to_table ORDER BY drinker_id limit 200, 10;

MySQL 回表[亲测有效]

explain分析:因为 drinker_id 字段不是索引,所以在分页查询需要进行回表查询,此时Extra为U sing filesort 文件排序,查询性能低下。

使用索引覆盖:建组合索引 idx_drinker_id_drinker_name_drinker_feature

#建立组合索引 idx_drinker_id_drinker_name_drinker_feature (`drinker_id`,`drinker_name`,`drinker_feature`)

CREATE INDEX idx_drinker_id_drinker_name_drinker_feature on t_back_to_table(`drinker_id`,`drinker_name`,`drinker_feature`);

再次根据 drinker_id 分页查询:

EXPLAIN SELECT id, drinker_id, drinker_name, drinker_feature FROM t_back_to_table ORDER BY drinker_id limit 200, 10;

MySQL 回表[亲测有效]

explain分析:此时的Extra字段为Using index表示使用了索引覆盖。

 

 

 

 

五花马
    千金裘
            呼儿将出换美酒
与尔同销万古愁
 

 

 

 

 

原文地址:https://www.cnblogs.com/taojietaoge/archive/2022/04/23/16167188.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/5345.html

(0)
上一篇 2023-05-13 12:30
下一篇 2023-05-13

相关推荐

  • Mysql大厂高频面试题「建议收藏」

    Mysql大厂高频面试题「建议收藏」前言 前几天有读者找到我,说想要一套全面的Mysql面试题,今天陈某特地为她写了一篇。 文章的目录如下: Mysql面试题 什么是SQL? 结构化查询语言(Structured Query Langu

    2023-02-19
    127
  • Apache Doris Roadmap 2021[亲测有效]

    Apache Doris Roadmap 2021[亲测有效]随着 Doris 越来越广泛的被在各个公司落地使用,Doris 开发团队也在不断地收集社区用户的需求和问题反馈。 为了更好地帮助用户了解 Doris 的发展方向和开发计划,百度 Doris 团队梳理…

    2023-04-10
    169
  • MongoDB学习(二) — 概念解析、命令行基本操作[亲测有效]

    MongoDB学习(二) — 概念解析、命令行基本操作[亲测有效]1、基础概念 下表将帮助您更容易理解Mongo中的一些概念: SQL术语/概念 MongoDB术语/概念 解释/说明 database database 数据库 table collection 数…

    2023-03-10
    141
  • Python Timeit模块使用指南

    Python Timeit模块使用指南在Python中,如果需要测量一段代码的执行时间,通常可以使用time模块,通过记录开始和结束时间,计算两个时间之差得到执行时间。但是,这种方法有以下缺点:一方面,time模块仅仅能够测量代码的全局执行时间,无法知道代码中每个语句执行所花费的时间;另一方面,在实际使用时,由于Python的解释执行方式,相邻代码执行顺序可能会产生微小的差异,导致测试结果不准确。对于这些问题,Python提供了Timeit模块来进行精确的时间测量。下面我们将详细介绍Timeit模块的使用。

    2024-08-07
    25
  • jdbc-实现用户登录业务(解决sql注入问题)[亲测有效]

    jdbc-实现用户登录业务(解决sql注入问题)[亲测有效]package com.cqust; import java.sql.*; import java.util.HashMap; import java.util.Map; import java.ut

    2023-04-28
    144
  • flink 原理_flink原理与实践图计算

    flink 原理_flink原理与实践图计算一、简介 开源流式处理系统在不断地发展,从一开始只关注低延迟指标到现在兼顾延迟、吞吐与结果准确性,在发展过程中解决了很多问题,编程API的易用性也在不断地提高。本文介绍一下 Flink 中的核心概念,

    2022-12-26
    140
  • 天启http,Python工程师必备的HTTP库

    天启http,Python工程师必备的HTTP库天启http是一个Python中的HTTP库,它使得和HTTP协议打交道变得更加容易。它提供了简单的API,支持GET和POST请求,并支持处理json数据。天启http使用了requests库作为底层实现,这使得它的操作更加高效。天启http是一个轻量级的HTTP库,使用简单、易于上手,并且在Python工程师中广受欢迎。

    2024-07-12
    32
  • 5分钟搞定 PostgreSQL 到 Doris 数据迁移和同步

    5分钟搞定 PostgreSQL 到 Doris 数据迁移和同步简述 Apache Doris 是一个现代化的 MPP 分析型数据库产品,仅需 亚秒级 响应时间即可获得查询结果,能有效地支持实时数据分析。 本文主要介绍如何使用 CloudCanal 快速构建一条稳

    2023-06-13
    169

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注