《MySQL高级篇》四、索引的存储结构(三)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用版 2核4GB 50GB
简介: 《MySQL高级篇》四、索引的存储结构

4.2 MyISAM 与 InnoDB 对比


MyISAM 的索引方式都是“非聚簇”的,与 InnoDB 包含 1 个聚簇索引是不同的


两种引擎中索引的区别:


在 InnoDB 存储引擎中,我们只需要根据主键值对 聚簇索引 进行一次查找就能找到对应的记录,而在 MyISAM 中却需要进行一次 回表 操作,意味着 MyISAM 中建立的索引相当于全部都是 二级索引 。(MyISAM的回表就是根据地址到data表中查找数据)

InnoDB 的数据文件本身就是索引文件,而 MyISAM 索引文件和数据文件是 分离的 ,索引文件仅保存数据记录的地址。

InnoDB 的非聚簇索引 data 域存储相应记录 主键的值 ,而 MyISAM 索引记录的是 地址 。换句话说, InnoDB 的所有非聚簇索引都引用主键作为 data 域。

MyISAM 的回表操作是十分 快速 的,因为是拿着地址偏移量直接到文件中取数据的,反观 InnoDB 是通过获取主键之后再去聚簇索引里找记录,虽然说也不慢,但还是比不上直接用地址去访问。

InnoDB 要求表 必须有主键 ( MyISAM 可以没有 )。如果没有显式指定,则 MySQL 系统会自动选择一个可以非空且唯一标识数据记录的列作为主键。如果不存在这种列,则 MySQL 自动为 InnoDB 表生成一个隐含字段作为主键,这个字段长度为 6 个字节,类型为长整型。

InnoDB的主键是为了生成聚簇索引,所以必须有;MyISAM 中的索引都是非聚簇的,数据和索引分离,所以对MyISAM没有要求。但是为了查询方便,还是建议指定某一字段为主键,从而方便存储引擎为其构建索引,提升查询效率。


fe19cd82d9cf65d2e0f4952ad7941a6a.png

bbd710f536ccb69f86c1042e17345c35.png


5. 索引的代价


索引是个好东西,可不能乱建,它在空间和时间上都会有消耗:


空间上的代价


每建立一个索引都要为它建立一棵 B+ 树,每一棵 B+ 树的每一个节点都是一个数据页,一个页默认会占用 16KB 的存储空间,一棵很大的 B+ 树由许多数据页组成,那就是很大的一片存储空间。


时间上的代价


每次对表中的数据进行 增、删、改操作时,都需要去修改各个 B+ 树索引。而且我们讲过,B+ 树每层节点都是按照索引列的值 从小到大的顺序排序 而组成了 双向链表 。不论是叶子节点中的记录,还是内节点中的记录(也就是不论是用户记录还是目录项记录)都是按照索引列的值从小到大的顺序而形成了一个单向链表。而增、删、改操作可能会对节点和记录的排序造成破坏,所以存储引擎需要额外的时间进行一些 记录移位 , 页面分裂 、 页面回收 等操作来维护好节点和记录的排序。如果我们建了许多索引,每个索引对应的 B+ 树都要进行相关的维护操作,会给性能拖后腿。


一个表上索引建的越多,就会占用越多的存储空间,在增删改记录的时候性能就越差。为了建立又好又少的索引,我们得学学这些索引在哪些条件下起作用的。


6. MySQL 数据结构选择的合理性


069fe14468027e9d1ba2f1caec38cf20.png


6.1 全表遍历


这里都懒得说了(加载所有页到内存,进行遍历查找,非常耗时,性能极差)


6.2 Hash 结构


da101252dfa41155a4d1578a69f4c356.png


f5aacf1991a8baaacaae04ee4fd21d3f.png


5d7bc97e479cae0904675a80339b2f15.png

92cab8c223fc5fcc9f4ed96402e16832.png


上图中哈希函数 h 有可能将两个不同的关键字映射到相同的位置,这叫做 碰撞 ,在数据库中一般采用链接法 来解决。在链接法中,将散列到同一槽位的元素放在一个链表中,如下图所示:


064232bddd7bf750490992bdf3163510.png


Hash 结构效率高,那为什么索引结构要设计成树型呢?


cc7d3606850fc18fa809970bf720c457.png


Hash 索引适用存储引擎如表所示:


索引 / 存储引擎 MyISAM InnoDB Memory
HASH 索引 不支持 不支持 支持


Hash索引的适用性


ad2e6b1fbb259308fdb7a1ecf94cb2af.png


ebd017479acede058eb57b91efc2dc58.png


采用自适应 Hash 索引目的是方便根据 SQL 的查询条件加速定位到叶子节点,特别是当 B+ 树比较深的时候,通过自适应 Hash 索引可以明显提高数据的检索效率。


我们可以通过 innodb_adaptive_hash_index 变量来查看是否开启了自适应 Hash,比如:


mysql> show variables like '%adaptive_hash_index';

f13b73c399f160824cdd428bde887ca1.png


6.3 二叉搜索树


951b95dff9b46d2a46fc442fa9356ef5.png

8478b653280b04c70d30bbf90eb65187.png


创造出来的二分搜索树如下图所示:


6793a789f161758e789d45c8980d8d42.png

3eab3242e242ef3f0df02c86ce9b68bf.png


6.4 AVL 树


01b5906df3ea4a11794c31616842a142.png


60bbbb5bff121ccf75d8904aa0f1697f.png

7f45786d2ebc67377055de34bb3ff7d8.png


7e662a2df18500fd8f522936bd790198.png


你能看到此时树的高度降低了,当数据量N大的时候,以及树的分叉数M大的时候,M叉树的高度会远小于二叉树的高度(M>2)。所以,我们需要把树从“瘦高"变"矮胖”。


6.5 B-Tree


B树的英文是Balance Tree,也就是多路平衡查找树。简写为B-Tree (注意横杠表示这两个单词连起来的意思,不是减号)。它的高度远小于平衡二叉树的高度。


B 树的结构如下图所示:


43caf3eb8d144cc8c8fcb8b205ef9859.png

cd754ea23fdf7a7f7d04cbcef6ca40ee.png


一个 M 阶的 B 树(M>2)有以下的特性:


根节点的儿子数的范围是 [2,M]。

每个中间节点包含 k-1 个关键字和 k 个孩子,孩子的数量 = 关键字的数量 +1,k 的取值范围为 [ceil(M / 2), M]。

叶子节点包括 k-1 个关键字(叶子节点没有孩子),k 的取值范围为 [ceil(M / 2), M]。

假设中间节点节点的关键字为:Key[1],Key[2],…,Key[k-1],且关键字按照升序排序,即 Key[i] < Key[i+1]。此时 k-1 个关键字相当于划分了 k 个范围,也就是对应着 k 个指针,即为:P[1],P[2],…,P[k],其中 P[1] 指向关键字小于 Key[1] 的子树,P[i] 指向关键字属于 (Key[i-1], Key[i])的子树,P[k] 指向关键字大于 Key[k-1] 的子树。

所有叶子节点位于同一层。

上面那张图所表示的 B 树就是一棵 3 阶的 B 树。我们可以看下磁盘块 2,里面的关键字为(8,12),它 有 3 个孩子 (3,5),(9,10) 和 (13,15),你能看到 (3,5) 小于 8,(9,10) 在 8 和 12 之间,而 (13,15) 大于 12,刚好符合刚才我们给出的特征。


然后我们来看下如何用 B 树进行查找。假设我们想要 查找的关键字是 9,那么步骤可以分为以下几步:


我们与根节点的关键字 (17,35)进行比较,9 小于 17 那么得到指针 P1;

按照指针 P1 找到磁盘块 2,关键字为(8,12),因为 9 在 8 和 12 之间,所以我们得到指针 P2;

按照指针 P2 找到磁盘块 6,关键字为(9,10),然后我们找到了关键字 9。

你能看出来在 B 树的搜索过程中,我们比较的次数并不少,但如果把数据读取出来然后在内存中进行比较,这个时间就是可以忽略不计的。而读取磁盘块本身需要进行 I/O 操作,消耗的时间比在内存中进行比较所需要的时间要多,是数据查找用时的重要因素。B 树相比平衡二叉树来说磁盘 I/O 操作更少, 在数据查询中比平衡二叉树效率要高。所以只要树的高度足够低,IO 次数足够少,就可以提高查询性能 。


小结


B树在插入和删除节点的时候如果导致树不平衡,就通过自动调整节点的位置来保持树的自平衡。


关键字集合分布在整棵树中,即叶子节点和非叶子节点都存放数据。搜索有可能在非叶子节点结束


其搜索性能等价于在关键字全集内做一次二分查找。


再举例 1:


371372f6203cc10b8c3782fb21a2ee42.png


**注意:**叶子节点和非叶子节点都存放数据。我们要查找C1:8,通过比较在磁盘块2中有对应的,那么数据就存在磁盘块2中


6.6 B+Tree


B+树也是一种多路搜索树,基于B树做出了改进,主流的DBMS都支持B+树的索引方式,比如MySQL。相比于B-Tree,B+Tree适合文件索引 系统。


MySQL 官网说明:


c16fb7466418bf9bafba26e01d3399b1.png


B+ 树和 B 树的差异:


有 k 个孩子的节点就有 k 个关键字。也就是孩子数量 = 关键字数,而 B 树中,孩子数量 = 关键字数 +1。

非叶子节点的关键字也会同时存在在子节点中,并且是在子节点中所有关键字的最大(或最小)。

非叶子节点仅用于索引,不保存数据记录,跟记录有关的信息都放在叶子节点中。而 B 树中,非叶子节点既保存索引,也保存数据记录 。

所有关键字都在叶子节点出现,叶子节点构成一个有序链表,而且叶子节点本身按照关键字的大小从小到大顺序链接。而B树中,叶子节点组成的链表是不完整的,还包含目录页中的数据

下图就是一棵B+树,阶数为3,根节点中的关键字1、18、 35分别是子节点(1, 8,14) ,(18, 24, 31)和(35, 41, 53) 中的最小值。每一层父节点的关键字都会出现在下一层的子节点的关键字中,因此在叶子节点中包括了所有的关键字信息,并且每一个叶子节点都有一个指向下一个节点的指针,这样就形成了一个链表。


6685ba2bdee7e8a1974c057546a45b7a.png

4c33b606ec38204970d7dffc0ba3000d.png


e74756a592c7e2be42a982fc7c7a9bed.png


fc8cb7f13cec30c82b33983f2f417732.png


B 树和 B+ 树都可以作为索引的数据结构,在 MySQL 中采用的是 B+ 树。


但 B 树和 B+ 树各有自己的应用场景,不能说 B+ 树完全比 B 树好,反之亦然。


697f5fc3203a713fc324b58c521f769e.png


8e0fbc72907b428464589ed13c647622.png


3a51988b0dbeebe02351b577e6d015ea.png


18cc808833b7774be5b92e648a679873.png

90e948cc25463d48aafabae09ae2d766.png

6.7 R 树


R-Tree 在 MySQL 很少使用,仅支持 geometry 数据类型 ,支持该类型的存储引擎只有 myisam、bdb、 innodb、ndb、archive 几种。举个 R 树在现实领域中能够解决的例子:查找 20 英里以内所有的餐厅。如果没有 R 树你会怎么解决?一般情况下我们会把餐厅的坐标(x,y)分为两个字段存放在数据库中,一个字段记录经度,另一个字段记录纬度。这样的话我们就需要遍历所有的餐厅获取其位置信息,然后计算是否满足要求。如果一个地区有 100 家餐厅的话,我们就要进行 100 次位置计算操作了,如果应用到谷歌、百度地图这种超大数据库中,这种方法便必定不可行了。R 树就很好的 解决了这种高维空间搜索问题。它把 B 树的思想很好的扩展到了多维空间,采用了 B 树分割空间的思想,并在添加、删除操作时采用合并、分解结点的方法,保证树的平衡性。因此,R 树就是一棵用来 存储高维数据的平衡树 。相对于 B-Tree,R-Tree 的优势在于范围查找。


索引 / 存储引擎 MyISAM InnoDB Memory
R-Tree 索引 支持 支持 不支持


6.8 小结


fe746fa86298d67148299587c810910e.png


面试中常考点:B+树和B-树的区别、B+树和Hash的区别


6.9 附录:算法的时间复杂度


同一问题可用不同算法解决,而一个算法的质量优劣将影响到算法乃至程序的效率。算法分析的目的在于选择合适算法和改进算法。

92cbf7ce7290cd2e29a3878f617d2a95.png



相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
6天前
|
存储 关系型数据库 MySQL
MySQL——数据库备份上传到阿里云OSS存储
MySQL——数据库备份上传到阿里云OSS存储
20 0
|
3天前
|
SQL 存储 关系型数据库
mysql加索引真的会锁表吗?揭秘背后的技术细节与规避策略
【8月更文挑战第16天】在数据库管理中,添加索引能大幅提升查询效率。MySQL执行此操作时的锁定行为常引起关注。文章详细解析MySQL中索引添加时的锁定机制及其原理。不同存储引擎及SQL语句影响锁定策略:MyISAM需全表锁定;InnoDB提供更灵活选项,如使用`ALTER TABLE... LOCK=NONE`可在加索引时允许读写访问,尽管可能延长索引构建时间。自MySQL 5.6起,在线DDL技术可进一步减少锁定时间,通过`ALGORITHM=INPLACE`和`LOCK=NONE`实现近乎无锁的表结构变更。合理配置这些选项有助于最小化对业务的影响并保持数据库高效运行。
12 4
|
3天前
|
SQL JavaScript 关系型数据库
Mysql索引不当引发死锁问题
本文通过真实案例解析了MySQL在高并发环境下出现死锁的问题。数据库表`t_award`包含多个索引,但在执行特定SQL语句时遭遇索引失效,导致更新操作变慢并引发死锁。分析发现,联合索引`(pool_id, identifier, status, is_redeemed)`因`identifier`允许为空值而导致索引部分失效。此外,`pool_id`上的普通索引产生的间隙锁在高并发下加剧了死锁风险。为解决此问题,文中提出了调整索引顺序至`(pool_id, status, is_redeemed, identifier)`等方案来优化索引使用,进而减轻死锁现象。
|
6天前
|
缓存 NoSQL Redis
一天五道Java面试题----第九天(简述MySQL中索引类型对数据库的性能的影响--------->缓存雪崩、缓存穿透、缓存击穿)
这篇文章是关于Java面试中可能会遇到的五个问题,包括MySQL索引类型及其对数据库性能的影响、Redis的RDB和AOF持久化机制、Redis的过期键删除策略、Redis的单线程模型为何高效,以及缓存雪崩、缓存穿透和缓存击穿的概念及其解决方案。
|
6天前
|
存储 小程序 关系型数据库
原生小程序 获取手机号并进行存储到mysql数据库
原生小程序 获取手机号并进行存储到mysql数据库
|
13天前
|
缓存 关系型数据库 MySQL
MySQL调优秘籍曝光!从索引到事务,全方位解锁高可用秘诀,让你的数据库性能飞起来!
【8月更文挑战第6天】MySQL是顶级关系型数据库之一,其性能直接影响应用的高可用性与用户体验。本文聚焦MySQL的高性能调优,从索引设计到事务管理,逐一解析。介绍如何构建高效索引,如联合索引`CREATE INDEX idx_order_customer ON orders(order_id, customer_id);`,以及索引覆盖查询等技术。
39 0
|
9天前
|
SQL 存储 关系型数据库
"MySQL增列必锁表?揭秘InnoDB在线DDL,让你的数据库操作飞一般,性能无忧!"
【8月更文挑战第11天】在数据库领域,MySQL凭借其稳定高效的表现深受开发者喜爱。对于是否会在给数据表添加列时锁表的问题,MySQL的行为受版本、存储引擎等因素影响。从5.6版起,InnoDB支持在线DDL,可在改动表结构时保持表的可访问性,避免长时间锁表。而MyISAM等则需锁表完成操作。例如,在使用InnoDB的表上运行`ALTER TABLE users ADD COLUMN email VARCHAR(255);`时,通常不会完全锁表。虽然在线DDL提高了灵活性,但复杂操作或大表变更仍可能暂时影响性能。因此,进行结构变更前应评估其影响并择机执行。
31 6
|
8天前
|
Oracle 关系型数据库 MySQL
Mysql和Oracle数据库死锁查看以及解决
【8月更文挑战第11天】本文介绍了解决MySQL与Oracle数据库死锁的方法。MySQL可通过`SHOW ENGINE INNODB STATUS`查看死锁详情,并自动回滚一个事务解除死锁;也可手动KILL事务。Oracle则通过查询V$LOCK与V$SESSION视图定位死锁,并用`ALTER SYSTEM KILL SESSION`命令终止相关会话。预防措施包括遵循ACID原则、优化索引及拆分大型事务。
|
9天前
|
固态存储 关系型数据库 MySQL
"惊!20亿数据秒速入MySQL,揭秘数据库极速插入的黑科技,你不可不知的绝密技巧!"
【8月更文挑战第11天】面对20亿级数据量,高效插入MySQL成为挑战。本文探讨优化策略:合理设计数据库减少不必要的字段和索引;使用批量插入减少网络往返;优化硬件如SSD和内存及调整MySQL配置;并行处理加速插入;附Python示例代码实现分批导入。这些方法将有效提升大规模数据处理能力。
25 2
|
10天前
|
存储 关系型数据库 MySQL
"Linux环境下MySQL数据库名及表名大小写敏感性设置详解:从配置到影响,确保数据库操作的准确与高效"
【8月更文挑战第9天】在Linux环境中,MySQL数据库名及表名的大小写敏感性是一项重要配置。默认情况下,MySQL在Linux上区分大小写,但这可通过配置文件 `/etc/my.cnf` 中的 `lower_case_table_names` 参数调整。该参数设为0时,名称存储时保持原样,查询时不区分大小写;设为1则全部转换为小写。通过编辑配置文件并重启MySQL服务,可根据需求灵活控制名称的大小写敏感性,确保数据一致性和应用兼容性。
28 3

热门文章

最新文章