MySQL的索引为什么使用B+树而不使用跳表?
MySQL的索引为什么使用B+树而不使用跳表?
在我们的印象中,mysql数据表里无非就是存储一行行的数据。跟个excel似的。
直接遍历这一行行数据,性能就是O(n),比较慢。为了加速查询,使用了B+树来做索引,将查询性能优化到了O(lg(n))。
但问题就来了,查询数据性能在 lg(n) 级别的数据结构有很多,比如redis的zset里用到的跳表,也是lg(n),并且实现还贼简单。
那为什么mysql的索引,不使用跳表呢?
我们今天就来聊聊这个话题。
1.B+树的结构
如上图,一般B+树是由多个页组成的多层级结构,每个页16Kb
,对于主键索引来说,最末级的叶子结点放行数据,非叶子结点放的则是索引信息(主键id和页号),用于加速查询。
比方说我们想要查找行数据5。会先从顶层页的record们入手。record里包含了主键id和页号(页地址)。关注黄色的箭头,向左最小id是1,向右最小id是7。那id=5的数据如果存在,那必定在左边箭头。于是顺着的record的页地址就到了6号
数据页里,再判断id=5>4,所以肯定在右边的数据页里,于是加载105号
数据页。
在105号数据页
里,虽然有多行数据,但也不是挨个遍历的,数据页内还有个页目录的信息,它可以通过二分查找的方式加速查询行数据,于是找到id=5的数据行,完成查询。
从上面可以看出,B+树利用了空间换时间的方式(构造了一批非叶子结点用于存放索引信息),将查询时间复杂度从O(n)优化为O(lg(n))。
2.跳表的结构
看完B+树,我们再来看下跳表是怎么来的。
同样的,还是为了存储一行行的数据。
我们可以将它们用链表串起来。
想要查询链表中的其中一个结点,时间复杂度是O(n),这谁顶得住,于是将部分链表结点提出来,再构建出一个新的链表。
这样当我想要查询一个数据的时候,我先查上层的链表,就很容易知道数据落在哪个范围,然后跳到下一个层级里进行查询。这样就把搜索范围一下子缩小了一大半。
比如查询id=10的数据,我们先在上层遍历,依次判断1,6,12,很快就可以判断出10在6到12之间,然后往下一跳,就可以在遍历6,7,8,9,10之后,确定id=10的位置。直接将查询范围从原来的1到10,变成现在的1,6,7,8,9,10,算是砍半了。
既然两层链表就直接将查询范围砍半了,那我多加几层,岂不妙哉?
于是跳表就这样变成了多层。
可以看出,跳表也是通过牺牲空间换取时间的方式提升查询性能。时间复杂度都是lg(n)。
3.B+树和跳表的区别
从上面可以看到,B+树和跳表的最下面一层,都包含了所有的数据,且都是顺序的,适合用于范围查询。往上的层级都是构建出来用于提升搜索性能的。这两者实在是太像了。但他们两者在新增和删除数据时,还是有些区别的。下面我们以新增数据为例聊一下。
1.B+树新增数据会怎么样
B+树本质上是一种多叉平衡二叉树。关键在于"平衡"这两个字,对于多叉树结构来说,它的含义是子树们的高度层级尽量一致(一般最多差一个层级),这样在搜索的时候,不管是到哪个子树分支,搜索次数都差不了太多。
当数据库表不断插入新的数据时,为了维持B+树的平衡,B+树会不断分裂调整数据页。
我们知道B+树分为叶子结点和非叶子结点。
当插入一条数据时,叶子结点和它上层的索引结点(非叶子结点)最大容量都是16k,它们都有可能会满。
为了简化问题,我们假设一个数据页只能放三条行数据或索引。
加入一条数据,根据数据页会不会满,分为三种情况。
叶子结点和索引结点都没满。这种情况最简单,直接插入到叶子结点中就好了。
叶子结点满了,但索引结点没满。此时需要拆分叶子结点,同时索引结点要增加新的索引信息。
叶子结点满了,且索引结点也满了。叶子和索引结点都要拆分,同时往上还要再加一层索引。
从上面可以看到,只有在叶子和索引结点都满了的情况下,B+树才会考虑加入一层新的结点。
要把三层B+树塞满,那大概需要2kw左右的数据。
跳表新增数据
跳表同样也是很多层,新增一个数据时,最底层的链表需要插入数据。
此时,是否需要在上面的几层中加入数据做索引呢?
这个就纯靠随机函数了。
理论上为了达到二分的效果,每一层的结点数需要是下一层结点数的二分之一。
也就是说现在有一个新的数据插入了,它有`50%`的概率需要在`第二层`加入索引,有`25%`的概率需要在`第三层`加个索引,以此类推,直到`最顶层`。
举个例子,如果跳表中插入数据id=6,且随机函数返回第三层(有25%的概率),那就需要在跳表的最底层到第三层都插入数据。
如果这个随机函数设计成上面这样,当数据量样本足够大的时候,数据的分布就符合我们理想中的"二分"。
跟上面B+树不一样,跳表是否新增层数,纯粹靠随机函数,根本不关心前后上下结点。
好了,基础科普也结束了,我们可以进入正题了。
4.Mysql的索引为什么使用B+树而不使用跳表?
B+树是多叉树结构,每个结点都是一个16k的数据页,能存放较多索引信息,所以扇出很高。三层左右就可以存储`2kw`左右的数据。也就是说查询一次数据,如果这些数据页都在磁盘里,那么最多需要查询三次磁盘IO。
跳表是链表结构,一条数据一个结点,如果最底层要存放`2kw`数据,且每次查询都要能达到二分查找的效果,`2kw`大概在`2的24次方`左右,所以,跳表大概高度在24层左右。最坏情况下,这24层数据会分散在不同的数据页里,也即是查一次数据会经历24次磁盘IO。
因此存放同样量级的数据,B+树的高度比跳表的要少,如果放在mysql数据库上来说,就是磁盘IO次数更少,因此B+树查询更快。
而针对写操作,B+树需要拆分合并索引数据页,跳表则独立插入,并根据随机函数确定层数,没有旋转和维持平衡的开销,因此跳表的写入性能会比B+树要好。
其实,mysql的存储引擎是可以换的,以前是`myisam`,后来才有的`innodb`,它们底层索引用的都是B+树。也就是说,你完全可以造一个索引为跳表的存储引擎装到mysql里。事实上,`facebook`造了个`rocksDB`的存储引擎,里面就用了跳表。直接说结论,它的写入性能确实是比innodb要好,但读性能确实比innodb要差不少。感兴趣的话,可以在文章最后面的参考资料里看到他们的性能对比数据。
5.redis为什么使用跳表而不使用B+树或二叉树呢?
redis支持多种数据结构,里面有个有序集合,也叫ZSET。内部实现就是跳表。那为什么要用跳表而不用B+树等结构呢?
这个几乎每次面试都要被问一下。
虽然已经很熟了,但每次都要装作之前没想过,现场思考一下才知道答案。
真的,很考验演技。
大家知道,redis 是纯纯的内存数据库。
进行读写数据都是操作内存,跟磁盘没啥关系,因此也**不存在磁盘IO**了,所以层高就不再是跳表的劣势了。
并且前面也提到B+树是有一系列合并拆分操作的,换成红黑树或者其他AVL树的话也是各种旋转,目的也是**为了保持树的平衡**。
而跳表插入数据时,只需要随机一下,就知道自己要不要往上加索引,根本不用考虑前后结点的感受,也就**少了旋转平衡的开销**。
因此,redis选了跳表,而不是B+树。
6.总结
B+树是多叉平衡搜索树,扇出高,只需要3层左右就能存放2kw左右的数据,同样情况下跳表则需要24层左右,假设层高对应磁盘IO,那么B+树的读性能会比跳表要好,因此mysql选了B+树做索引。
redis的读写全在内存里进行操作,不涉及磁盘IO,同时跳表实现简单,相比B+树、AVL树、少了旋转树结构的开销,因此redis使用跳表来实现ZSET,而不是树结构。
存储引擎RocksDB内部使用了跳表,对比使用B+树的innodb,虽然写性能更好,但读性能属实差了些。在读多写少的场景下,B+树依旧YYDS。
原文来自————微信公众号文章
MySQL的索引为什么使用B+树而不使用跳表?的更多相关文章
- 为什么 MySQL 索引要使用 B+树而不是其它树形结构?比如 B 树?
一个问题? InnoDB一棵B+树可以存放多少行数据?这个问题的简单回答是:约2千万 为什么是这么多呢? 因为这是可以算出来的,要搞清楚这个问题,我们先从InnoDB索引数据结构.数据组织方式说起. ...
- 面试官:为什么MySQL的索引要使用B+树,而不是其它树?比如B树?
InnoDB的一棵B+树可以存放多少行数据? 答案:约2千万 为什么是这么多? 因为这是可以算出来的,要搞清楚这个问题,先从InnoDB索引数据结构.数据组织方式说起. 计算机在存储数据的时候,有最小 ...
- 为什么MySQL数据库索引选择使用B+树?
在进一步分析为什么MySQL数据库索引选择使用B+树之前,我相信很多小伙伴对数据结构中的树还是有些许模糊的,因此我们由浅入深一步步探讨树的演进过程,在一步步引出B树以及为什么MySQL数据库索引选择使 ...
- B树和B+树对比,为什么MySQL数据库索引选择使用B+树?
一 基础知识 二叉树 根节点,第一层的节点 叶子节点,没有子节点的节点. 非叶子节点,有子节点的节点,根节点也是非叶子节点. B树 B树的节点为关键字和相应的数据(索引等) B+树 B+树是B树的一个 ...
- 【深入学习MySQL】MySQL的索引为什么使用B+树?
前言 在MySQL中,无论是Innodb还是MyIsam,都使用了B+树作索引结构(这里不考虑hash等其他索引).本文将从最普通的二叉查找树开始,逐步说明各种树解决的问题以及面临的新问题,从而说明M ...
- 为什么MySQL索引要使用 B+树,而不是其它树形结构?
作者:李平 https://www.cnblogs.com/leefreeman/p/8315844.html 一个问题? InnoDB一棵B+树可以存放多少行数据?这个问题的简单回答是:约2千万 为 ...
- MySQL存储索引InnoDB数据结构为什么使用B+树,而不是其他树呢?
InnoDB的一棵B+树可以存放多少行数据? 答案:约2千万 为什么是这么多? 因为这是可以算出来的,要搞清楚这个问题,先从InnoDB索引数据结构.数据组织方式说起. 计算机在存储数据的时候,有最小 ...
- MySQL用B+树(而不是B树)做索引的原因
众所周知,MySQL的索引使用了B+树的数据结构.那么为什么不用B树呢? 先看一下B树和B+树的区别. B树 维基百科对B树的定义为"在计算机科学中,B树(B-tree)是一种树状数据结构, ...
- MySQL数据库索引之B+树
一.B+树是什么 B+ 树是一种树型数据结构,通常用于数据库和操作系统的文件系统中.B+ 树的特点是能够保持数据稳定有序,其插入与修改操作拥有较稳定的对数时间复杂度.B+ 树元素自底向上插入,这与二叉 ...
- 数据库——MySQL——索引——索引原理及B+树
索引原理 我们使用索引,就是为了提高查询的效率,如同查书一样,先找到章,再找到章中对于的小节,再找到具体的页码,再到我们需要的内容. 事实上索引的本质就是不断缩小获取数据的筛选范围,找出我们想要的结果 ...
随机推荐
- 论文解读(APCA)《Adaptive prototype and consistency alignment for semi-supervised domain adaptation》
[ Wechat:Y466551 | 付费咨询,非诚勿扰 ] 论文信息 论文标题:Adaptive prototype and consistency alignment for semi-super ...
- 从一些常见的错误聊聊mysql服务端的关键配置
背景 每一年都进行大促前压测,每一次都需要再次关注到一些基础资源的使用问题,订单中心这边数据库比较多,最近频繁报数据库异常,所以对数据库一些配置问题也进行了研究,本文给出一些常见的数据库配置,说明这些 ...
- PhotoShop Beta(爱国版)安装教程-内置AI绘画功能
PS beta版安装教程 Window和Mac版都有,里面内置AI绘画功能 ps Beta版真的太爽了,今天来和大家分享下安装教程. 很多人拿这资料卖5块 9.9 19.9,球友们直接用,建议赶紧装, ...
- RocketMQ 系列(三) 集成 SpringBoot
RocketMQ 系列(三) 集成 SpringBoot 前两篇文章介绍了 RocketMQ 基本概念与搭建,现在以它与 SpringBoot 的结合来介绍其基本的用法. RocketMQ系列(一) ...
- 加密 K8s Secrets 的几种方案
前言 你可能已经听过很多遍这个不算秘密的秘密了--Kubernetes Secrets 不是加密的!Secret 的值是存储在 etcd 中的 base64 encoded(编码) 字符串.这意味着, ...
- Spring Boot虚拟线程与Webflux在JWT验证和MySQL查询上的性能比较
早上看到一篇关于Spring Boot虚拟线程和Webflux性能对比的文章,觉得还不错.内容较长,我就不翻译了,抓重点给大家介绍一下这篇文章的核心内容,方便大家快速阅读. 测试场景 作者采用了一个尽 ...
- fepk文件格式说明
1 卫星影像金字塔分块原理说明 通常我们在工作中使用的卫星影像数据,轻则几百M,重则几百个G甚至上TB级.影像数据太大,是大家经常会遇到的一个问题,尤其是想下载一个省以上数据的时候该问题尤为突出.那 ...
- TrueUpdate白加黑木马分析保姆级教程
目录 TrueUpdate白加黑木马分析保姆级教程 0x00:前言 TrueUpdate是什么? 0x01: TrueUpdate逆向分析解压密码 查壳 脱壳 分金定穴 找到解压密码方法1: 找到解压 ...
- Redis系列之——Redis-Cluster
文章目录 一 Redis Cluser介绍背景 1.1问题 1.2 解决 二 数据分布(分布式数据库) 2.1 存在问题 2.2 分区方式 2.2.1 顺序分区 2.2.2 哈希分区 2.2.2 .1 ...
- Markdown · Typora | 基本画图技巧
如果想画一些简单的状态图,可以使用 typora 自带的 mermaid 工具. (mermaid 不止能画简单的状态图,还能画流程图等,详见参考资料) 定义节点 可以定义不同形状的节点,并为节点添加 ...