【MySQL从入门到精通】【高级篇】(八)聚簇索引&非聚簇索引&联合索引

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 上一篇文章我们介绍了【MySQL从入门到精通】【高级篇】(七)设计一个索引&InnoDB中的索引方案,该文介绍了如何设计一个索引,以及InnoDB中的索引如何形成。

1. 简介

上一篇文章我们介绍了【MySQL从入门到精通】【高级篇】(七)设计一个索引&InnoDB中的索引方案,该文介绍了如何设计一个索引,以及InnoDB中的索引如何形成。

这篇文章接着来介绍InnoDB的索引,索引按照物理实现方式,索引可以分为2种聚簇索引和非聚簇索引。我们也把非聚簇索引称为二级索引或者辅助索引。

2. 环境

环境 版本
Red Hat 4.8.5-39
MySQL 5.7

3. 聚簇索引

聚簇索引并不是一种索引类型,而是一种数据存储方式(所有的用户记录都存储在了叶子节点),也就是所谓的索引即数据,数据即索引。

术语:“聚簇” 表示数据行和相邻的键值聚簇的存储在一起。

特点:

使用记录主键值的大小进行记录和页的排序,这包含三个方面的含义:

页内的记录是按照主键值的大小顺序排成一个单向链表。

各个存放用户记录的页也是根据页中用户记录的主键大小顺序排成了一个双向链表。

存放目录项记录的页分为不同的层次,在同一层次中的页也是根据页中目录项记录的主键大小顺序排成一个双向链表。

B+树的叶子节点存储的是完整的用户记录。

所谓完整的用户记录就是指这个记录中存储了所有列的值(包括隐藏列)。

我们把具有这两种特性的B+树称为聚簇索引,所有完整的用户记录都存放在这个聚簇索引的叶子节点处。这种聚簇索引并不需要我们在MySQL中通过INDEX语句去创建,InnoDB存储引擎会自动的为我们创建聚簇索引。

优点

数据访问更快,因为聚簇索引将索引和数据保存在同一个B+树中,因此从聚簇索引中获取数据比非聚簇索引更快。

聚簇索引对于主键的排序查找和范围查找速度非常快。

按照聚簇索引排列顺序,查询显示一定范围数据的时候,由于数据都是紧密相连,数据库不用从多个数据块中提取数据,所以节省了大量的IO操作。

缺点:

插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式,否则将会出现页分裂,严重影响性能。因此,对于InnoDB表,我们一般都会定义一个自增的ID列为主键。

更新主键的代价非常高,因为将会导致被更新的行移动,因此,对于InnoDB表,我们一般定义主键不可更新。

二级索引访问需要两次索引查找,第一次找到主键值,第二次根据主键值找到行数据。

限制:

对于MySQL数据库目前只有InnoDB数据引擎支持聚簇索引,而MyISAM并不支持聚簇索引。

由于数据物理存储排序方式只能有一种,所以每个MySQL的表只能有一个聚簇索引。一般情况下就是该表的主键。

如果没有定义主键,InnoDB会选择非空的唯一索引代替,如果没有这样的索引,InnoDB会隐式的定义一个主键来作为聚簇索引。

为了充分利用聚簇索引的聚簇的特性,所以InnoDB表的主键列尽量选用有序的顺序id,而不建议用无序的id,比如UUID、MD5、HASH、字符串列作为主键无法保证数据的顺序增长。

4. 非聚簇索引(二级索引,辅助索引)

上边的聚簇索引只有在搜索条件是主键值时才能发挥作用,因为B+树中的数据都是按照主键进行排序的。那如果我们想以别的列作为搜索条件该怎么办呢?肯定不能是从头到尾沿着链表依次遍历记录一遍。

答案是:我们可以多建几棵B+树,不同的B+树中的数据采用不同的排序规则,比如我们使用age列的大小作为数据页中记录的排序规则,再建一棵B+树,效果如下图所示:

使用记录age列的大小进行记录和页的排序,这包含三个方面的含义:

页中的记录是按照age列的大小顺序排成一个单向链表。

各个存放用户记录的页也是根据页中记录的age列大小顺序排成一个双向链表。

存放目录项记录的页分为不同的层次,在同一层次中的页也是根据页中目录项记录的age列大小顺序排成一个双向链表。

目录项记录中不再是主键+页号,而变成了age列+页号的搭配。

所以如果我们现在想通过age列的值查找某些记录的话就可以使用我们刚刚建好的这个B+树了,以查找age列的值为28为例,查找过程如下;

确定目录项记录页

根据根页面,也就是页33,可以快速定位到目录项记录所在的页为页42

通过目录项记录页确定用户记录真实所在的页。

在页42中可以快速定位到目录项记录 所在的页为页46 (因为20<28<30)。

在真实存储用户记录的页中定位到具体的记录。

但是这个B+树的叶子节点中的记录只存储了age和id(也就是主键)两个列,所以我们必须再根据主键值去聚簇索引中再查找一遍完整的用户记录。

4.1. 回表

我们根据这个以age列大小排序的B+只能确定我们要查找记录的主键值,所以如果我们想根据age列的值查找到完整的用户记录的话,仍然需要到聚簇索引中再查一遍,这个过程称为回表。也就是根据age列的值查询一条完整的用户记录需要使用2棵B+树。

问题:为什么我们还需要一次回表操作呢?直接把完整的用户记录放在叶子节点不可以么?

回答:如果把完整的用户记录放到叶子节点的话就可以不用回表了,但是非聚簇索引不止一个,如果每建立一棵B+树都需要将完整把所有的用户记录都在拷贝一次遍的话,这样就太浪费存储空间了。

因为这种按照非主键列建立的B+树需要一次回表操作才可以定位到完整的用户记录,所以这种B+树也被称为二级索引 ,或者辅助索引。由于我们使用的是age列的大小作为B+树的排序规则,所以我们也称这个B+树为age列建立的索引。

非聚簇索引的存在不影响数据在聚簇索引中的组织,所以在一张表可以有多个非聚簇索引。

5. 联合索引

我们也可以同时以多个列的大小作为排序规则,也就是同时为多个列建立索引,比方说我们想让B+树按照age列和name列的大小进行排序,这个包含两个含义:

1.先把各个记录和页按照age列进行排序。

2.在记录的age列相同的情况下,采用name列进行排序。
为age列和name列建立的索引的示意图如下:

如图所示,我们需要注意以下几点:

每条目录项记录都由age、name、页号这三个部分组成,各条记录先按照age列的值进行排序,如果记录的age列相同,则按照name列的值进行排序。

B+树叶子节点处的用户记录由age,name和主键id列组成。

注意一点,以age列和name列的大小为排序规则建立的B+树称为联合索引,本质上也是一个二级索引。它的意思与分别为age和name列分别建立索引的表述不同,不同点如下;

建立联合索引 只会建立如上图一样的一棵B+树。

为age和name列分别建立索引会分别以age和name列的大小为排序规则建立两棵B+树。

总结

本文详细介绍了聚簇索引,非聚簇索引和联合索引,MySQL会默认以主键列创建一个聚簇索引,用于存储完整的用户记录数据,而非聚簇索引和联合索引只会存储索引列以及主键。根据非聚簇索引查询完整的用户记录需要进行回表查询。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
3天前
|
算法 关系型数据库 MySQL
MySQL (索引 & 事务)
MySQL (索引 & 事务)
18 3
|
3天前
|
存储 关系型数据库 MySQL
MySQL索引
MySQL索引
9 0
|
4天前
|
SQL 算法 关系型数据库
【MySQL】索引介绍、索引的数据结构
【MySQL】索引介绍、索引的数据结构
18 0
|
7天前
|
存储 数据采集 关系型数据库
?MySQL是如何保证唯一性索引的唯一性的?
MySQL使用B树实现唯一性索引,确保高效检索和插入。事务机制和锁定协议维护InnoDB存储引擎的唯一性。唯一索引可允许NULL值,且InnoDB允许多个NULL。唯一索引查询速度快,能提升数据质量,但插入和更新时需检查唯一性,可能影响性能。
|
7天前
|
存储 关系型数据库 MySQL
MySQL的索引, 到底怎么创建?
MySQL的索引, 到底怎么创建?
26 2
|
7天前
|
存储 关系型数据库 MySQL
MySQL索引事务
MySQL索引事务
18 0
|
9天前
|
存储 算法 关系型数据库
【MySQL】索引(重点)-- 详解(下)
【MySQL】索引(重点)-- 详解(下)
|
9天前
|
存储 关系型数据库 MySQL
【MySQL】索引(重点)-- 详解(上)
【MySQL】索引(重点)-- 详解(上)
|
16天前
|
SQL 存储 关系型数据库
必知的 MySQL 索引失效场景【包括实践验证】,别再踩坑了!(下)
必知的 MySQL 索引失效场景【包括实践验证】,别再踩坑了!
89 2
|
16天前
|
SQL 关系型数据库 MySQL
必知的 MySQL 索引失效场景【包括实践验证】,别再踩坑了!(上)
必知的 MySQL 索引失效场景【包括实践验证】,别再踩坑了!
53 2
http://www.vxiaotou.com