InnoDB主键索引树和二级索引树的场景分析

我们这里讨论InnoDB存储引擎,数据和索引存储在同一个文件student.ibd

场景1:主键索引树

uid是主键,其他字段没有添加任何索引

select * from student;

如果是这样查询,这表示整表搜索,从左到右遍历叶子节点链表,从小到大访问

select * from student where uid<5;

如果是这样查询,这表示范围查询,就直接在有序链表中遍历搜索就可以了,直到遍历到第一个不小于5的key结束遍历

select * from student where uid=5;

如果是这样查询,这表示等值查询,在索引树上进行二分查找即可

由于name没有索引,于是做整表搜索

select * from student where name='linfeng';

场景2:二级索引树

uid是主键,以name创建了普通索引(二级索引)

以name为索引构建的索引树,称为辅助索引树,也叫做二级索引树。key是辅助索引字段name的值,然后还有外加uid主键的值

在辅助索引树上,key是辅助索引的值,也就是name;data数据值是所在记录行的主键值(PRIMARY KEY),也就是uid(并不是表的一行数据)

分析语句1:

select name from student where name='linfeng';

因为过滤字段是name且 只select了name一个字段,name有索引,索引树上直接就有,所以从name的二级索引树上去等值匹配linfeng

分析语句2:

select uid,name from student where name='linfeng';

这种情况select的是name和uid,而这些在二级索引树上也是直接就有,所以搜索二级索引树就完事了。

分析语句3:

select * from student where name='linfeng';

这种情况下就涉及到回表了,这是一个很重要的概念。由于name字段有索引,所以我们会到name字段构建的二级索引树上去查找。但二级索引树没有linfeng这个人所有的信息,所以完整的查询过程应该是这样的:

  • 用linfeng到二级索引树上进行匹配,拿到二级索引树上存储的uid
  • 然后拿着这个uid去主索引树上去匹配,最后拿到linfeng的所有信息(回表

而这个回表意味着更多的磁盘I/O,会影响效率,如果业务只需要uid、name,就别写select *了,这样可以避免回表

分析语句4:

我们删除name的索引后执行以下语句

select * from student where age=20 order by name;

没有用到索引,还使用外部排序了。此外我们还看到using filesort,这时需要优化了。

我们的过滤条件是age,先给age添加索引,看看行不行

可以看到,age命中索引了,查询age所在的索引树。由于我们写的是select *,依然存在回表。还有using filesort,因为使用age=20查询到的结果是多个,然而name此时是没有顺序的,所以还需要再进行外部排序。

那能不能通过给name加载索引来解决问题呢?

不能,因为一次SQL执行只能用到1个索引,搜索了这个字段的索引树就不会再去搜索另一个字段的索引树了,因为加载索引是要耗费磁盘I/O的,查找多个索引树就太慢了!

分析:既然索引树上只能存自己建立的索引字段以及主键,那我们把需要查询的字段都设置成索引不就好了?

解决方法:我们可以在二级索引树上的key:age+name,形成联合索引,先按age排序,age相同了,再按name排序

再次select *

这时候就使用到联合索引了,而且没有using filesort,这次是这样查询的:

先用age=20在辅助索引树上查找,如果数据足够会找到多个结果,这个结果就是已经排好序的,不需要再using filesort

我们现在直接用第二个字段name作为过滤条件

我们看到这里没有用到索引,因为我们用(age,name)创建索引,是先按age排序,再按name排序。如果我们只用name作为过滤条件,这就没有办法使用索引匹配了,因为是优先用age排序。

所以我们经常说,多列索引一定要使用到第1个字段,这样才能用到索引!

在建立(age,name)联合索引的情况下,以下操作不回表(到二级索引树上搜索,再去主索引树上搜索):

  • select age
  • select age, name
  • select uid,age,name

以下操作要回表

  • select *
  • select age,name,sex

到此这篇关于InnoDB主键索引树和二级索引树的文章就介绍到这了,更多相关InnoDB索引树内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • innodb_index_stats导入备份数据时报错表主键冲突的解决方法

    故障描述 percona5.6,mysqldump全备份,导入备份数据时报错Duplicate entry 'hoc_log99-item_log_27-PRIMARY-n_diff_pfx01' for key 'PRIMARY' 故障原因 查看了下这个主键应该是MySQL系统库下的系统表innodb_index_stats mysql> show create table innodb_index_stats\G *************************** 1. row ****

  • MySQL异常恢复之无主键情况下innodb数据恢复的方法

    本文讲述了MySQL异常恢复之无主键情况下innodb数据恢复的方法.分享给大家供大家参考,具体如下: 在mysql的innodb引擎的数据库异常恢复中,一般都要求有主键或者唯一index,其实这个不是必须的,当没有index信息之时,可以在整个表级别的index_id进行恢复 创建模拟表-无主键 mysql> CREATE TABLE `t1` ( -> `messageId` varchar(30) character set utf8 NOT NULL, -> `tokenId`

  • InnoDB主键索引树和二级索引树的场景分析

    我们这里讨论InnoDB存储引擎,数据和索引存储在同一个文件student.ibd 场景1:主键索引树 uid是主键,其他字段没有添加任何索引 select * from student; 如果是这样查询,这表示整表搜索,从左到右遍历叶子节点链表,从小到大访问 select * from student where uid<5; 如果是这样查询,这表示范围查询,就直接在有序链表中遍历搜索就可以了,直到遍历到第一个不小于5的key结束遍历 select * from student where u

  • MySQL 主键与索引的联系与区别分析

    关系数据库依赖于主键,它是数据库物理模式的基石.主键在物理层面上只有两个用途: 惟一地标识一行. 作为一个可以被外键有效引用的对象. 索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分),它们包含着对数据表里所有记录的引用指针.下面是主键和索引的一些区别与联系. 1. 主键一定是唯一性索引,唯一性索引并不一定就是主键. 所谓主键就是能够唯一标识表中某一行的属性或属性组,一个表只能有一个主键,但可以有多个候选索引.因为主键可以唯一标识某一行记录,所以可以确保执行数据更新.删除的

  • 主键与聚集索引

    主键(PRIMARY KEY ) 来自MSDN的描述: 表通常具有包含唯一标识表中每一行的值的一列或一组列.这样的一列或多列称为表的主键 (PK),用于强制表的实体完整性.在创建或修改表时,您可以通过定义 PRIMARY KEY 约束来创建主键. 一个表只能有一个 PRIMARY KEY 约束,并且 PRIMARY KEY 约束中的列不能接受空值.由于 PRIMARY KEY 约束可保证数据的唯一性,因此经常对标识列定义这种约束. 如果为表指定了 PRIMARY KEY 约束,则 SQL Ser

  • 解决mysql的int型主键自增问题

    引入 我们在使用mysql数据库时,习惯使用int型作为主键,并设置为自增,这既能够保证唯一,使用起来又很方便,但int型的长度是有限的,如果超过长度怎么办呢? 暴露问题 我们先创建一个测试表,创建语句如下: CREATE TABLE test1 ( id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR(20) ) 然后我们插入两条数据: INSERT INTO test1 VALUES(NULL,'小牛'); INSERT INTO test1 VAL

  • SQL Server 创建约束图解(唯一 主键)

    SQLServer中有五种约束,Primary Key约束.Foreign Key约束.Unique约束.Default约束和Check约束,今天使用SQL Server2008来演示下这几种约束的创建和使用的方法. 什么是主键? 在数据库中,常常不只是一个表,这些表之间也不是相互独立的.不同的表之间需要建立一种关系,才能将它们的数据相互沟通.而在这个沟通过程中,就需要表中有一个字段作为标志,不同的记录对应的字段取值不能相同,也不能是空白的.通过这个字段中不同的值可以区别各条记录.就像我们区别不

  • 浅析MySQL 主键使用数字还是uuid查询快

    在实际开发中mysql的主键不能重复,可能会采用主键自增,为了防止主键重复也可能会采取雪花算法之类的算法保证,这两种主键保存的都是number类型 但是实际开发中可能会生成uuid作为主键那么疑问来了,到底哪种主键的效率高呢? 下面由测试来验证: 1.首先我们先创建一个表,用存储过程生成100w条数据然后分析: 创建表: CREATE TABLE `my_tables` ( `id` VARCHAR(32) NOT NULL , `name` varchar(32) DEFAULT NULL,

  • 深入探寻mysql自增列导致主键重复问题的原因

    废话少说,进入正题. 拿到问题后,首先查看现场,发现问题表的中记录的最大值比自增列的值要大,那么很明显,当有记录进行插入时,自增列产生的值就有可能与已有的记录主键冲突,导致出错.首先想办法解决问题,通过人工调大自增列的值,保证大于表内已有的主键即可,调整后,导数据正常.问题是解决了,接下来要搞清楚问题原因,什么操作导致了这种现象的发生呢? 这里有一种可能,即业务逻辑包含更新自增主键的代码,由于mysql的update动作不会同时更新自增列值,若更新主键值比自增列大,也会导致上述现象:记录最大值比

  • MySQL8新特性:自增主键的持久化详解

    前言 自增主键没有持久化是个比较早的bug,这点从其在官方bug网站的id号也可看出(https://bugs.mysql.com/bug.php?id=199).由Peter Zaitsev(现Percona CEO)于2003年提出.历史悠久且臭名昭著. 首先,直观的重现下. mysql> create table t1(id int auto_increment primary key); Query OK, 0 rows affected (0.01 sec) mysql> inser

  • Mysql InnoDB聚簇索引二级索引联合索引特点

    目录 一.聚簇索引 特点 1 特点 2 二.二级索引 三.联合索引 接上一篇内容:https://www.jb51.net/article/249934.htm 一.聚簇索引 其实之前内容中介绍的 B+ 树就是聚簇索引. 这种索引不需要我们显示地使用 INDEX 语句去创建,InnoDB 引擎会自动创建.另外,在 InnoDB 引擎中,聚簇索引就是数据的存储方式. 它有 2 个特点: 特点 1 使用记录主键值的大小进行记录和页的排序. 其中又包含了下面 3 个点: 页(包括叶节点和内节点)内的记

  • MySQL InnoDB 二级索引的排序示例详解

    排序问题 最近看了极客时间上 <MySQL实战45讲>,纠正了一直以来对 InnoDB 二级索引的一个理解不到位,正好把相关内容总结下. PS:本文的所有测试基于 MySQL 8.0.13 . 先把问题抛出来,下面的 SQL 所创建的表,有两个查询语句,哪个索引是非必须的? CREATE TABLE `geek` ( `a` int(11) NOT NULL, `b` int(11) NOT NULL, `c` int(11) NOT NULL, `d` int(11) NOT NULL, P

随机推荐