B+Tree

要回答好这个问题，首先我们要弄懂什么是索引？索引常见的数据结构有哪些？这些数据结构有何优缺点？只有弄懂这些，再去比较，才会知道为啥要用B+树作为MySQL数据库的存储索引了。 一、索引是什么？ MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。它的本质就是 数据结构 ，单独存储在磁盘上，用它来提高数据查询的效率。 适合作为索引的结构应该是尽可能少的执行磁盘IO操作，因为执行磁盘IO操作非常的耗时。 二、索引常见数据结构 2.1 二叉查找树（Binary Search Tree） 采取二分查找的思想，O（log N）的复杂度就可以完成对数据的查找任务，查找所需的最大次数等同于二叉查找树的高度。 它具有以下特性： 左子树上所有结点的值均小于或等于它的根结点的值； 右子树上所有结点的值均大于或等于它的根结点的值； 左、右子树也分别为二叉排序树。 如下图所示： 排序工具 对该二叉树的节点进行查找发现深度为1的节点的查找次数为1，深度为2的查找次数为2，深度为n的节点的查找次数为n，因此其平均查找次数为 (1+2+2+3+3+3) / 6 = 2.3次 二叉查找树可以任意地构造，这样会出现一种极端情况，如果依次插入如下六个节点：7，6，5，4，那么就会变成下图所示： 这样退化成线性表，导致树高度过高，从而查询效率就降低了。

索引 是帮助MySQL高效获取的数据的 排好序 的 数据结构 B Tree 结构 叶子节点具有相同的深度，叶子节点的指针为空， 所有索引元素不重复， 叶子节点的数据从左往右递增排列 B+Tree 索引 非叶子节点不存储data，只存储索引，可以放更多索引 叶子节点包含所有的索引字段， 叶子之间使用指针链接（单向），提高区间访问性能 MySQL所使用的 B+Tree索引，经过了改造，叶子节点之家使用双向指针链接 。 默认一个节点大小为16kb MyISAM 存储引擎 非聚集索引，索引文件和数据分离，叶子节点里面data，存储的是数据地址 InnoDb 存储引擎 主键索引属于聚集索引，叶子节点data里面包含了完整的数据记录 非主键索引属于非聚集索引，为了数据的一致性和节省存储空间，叶子节点data里面存储了主键ID Hash 索引 根据查询key值，通过hash算法，以及hash表，直接可以定位到数据存储的地址，效率非常高，不受数据量影响 不支持模糊查询，不支持范围查询，不支持排序 联合索引结构 按照创建联合主键几个字段的顺序进行排序，组合保存在B+Tree的叶子节点 来源： https://my.oschina.net/u/3519302/blog/3128263

典型的3种存储引擎 1、hash： 代表：nosql的redis/memcached 本质为： 基于(内存中)的hash； 所以支持 随机 的增删查改，读写的时间复杂度O(1)； 但是无法支持顺序读写(注，这里指典型的hash，不是指如redis的基于跳表的zset的其他功能)； 基本效果：在不需要有序遍历时，最优 2、磁盘查找树： 代表：mysql 本质为：基于(磁盘的)顺序查找树，B树/B+树； 基本效果：支持有序遍历；但数据量很大后，随机读写效率低(原因往下看)； 3、lsmtree： 代表：hbase/leveldb/rocksdb 本质为： 实际落地存储的数据按key划分，形成有序的不同的文件； 结合其“先内存更新后合并落盘”的机制，尽量达到磁盘的写是顺序写，尽可能减少随机写； 对于读，需合并磁盘已有历史数据和当前未落盘的驻于内存的更新，较慢； 基本效果：也可以支持有序增删查改；写速度大幅提高；读速度稍慢； B树 B树是一种平衡多路搜索树，B树与红黑树最大的不同在于，B树的结点可以有多个子女，从几个到几千个。那为什么又说B树与红黑树很相似呢?因为与红黑树一样，一棵含n个结点的B树的高度也为O（lgn），但可能比一棵红黑树的高度小许多，应为它的分支因子比较大。所以，B树可以在O（logn）时间内，实现各种如插入（insert），删除（delete）等动态集合操作。

一、LSM-Tree概述 核心思想就是放弃部分读能力，换取写入能力的最大化。LSM-Tree ，这个概念就是结构化合并树（Log-Structured Merge Tree）的意思，它的核心思路其实非常简单，就是假定内存足够大，因此不需要每次有数据更新（插入、删除）就必须将数据写入到磁盘中，而可以先将最新的数据驻留在内存中，等到积累到一定限制大小之后，再使用归并排序的方式将内存中的数据合并追加到磁盘队尾(因为所有待合并的树都是有序的，可以通过合并排序的方式快速合并到一起)。 磁盘的技术特性:对磁盘来说，能够最大化的发挥磁盘技术特性的使用方式是:一次性的读取或写入固定大小的一块数据，并尽可能的减少随机寻道这个操作的次数。 日志结构的合并树（LSM-tree）是一种基于硬盘的数据结构，与B+ tree相比，能显著地减少硬盘磁盘寻道开销，并能在较长的时间提供对文件的高速插入（删除）。然而LSM-tree在某些情况下，特别是在查询需要快速响应时性能不佳。通常LSM-tree适用于索引插入比检索更频繁的应用系统。 二、LSM-Tree VS B+ Tree B+Tree RDBMS一般采用B+树作为索引的数据结构。RDBMS中的B+树一般是3层n路的平衡树。B+树的节点对应于磁盘数据块。因此对于RDBMS，数据更新操作需要5次磁盘操作（从B+树3次找到记录所在数据块，再加上一次读和一次写）

B-Tree是为磁盘等外存储设备设计的一种平衡查找树。先了解磁盘的相关知识: 1.系统从磁盘读取数据到内存时是以磁盘块为基本单位的，位于同一磁盘块中的数据会被一次性的读取出来，而不是需要什么读取什么。 2.InnerDB存储引擎中是有页(Page)的概念，页是其管理的最小单位。默认每页的大小为16KB，可以设置。InnerDB在把磁盘数据读入内存的时候，会以页为基本单位。B-Tree的结构可以让系统高效的找到数据所在的磁盘块。 来源： https://my.oschina.net/u/3126880/blog/3111485

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/m0_37609579/article/details/100107832 前文讲了二叉树和多路树，二叉树的性能很好，像AVL树、红黑树都是很优秀的结构，那么在数据库索引中，并没有采用二叉树这种结构，这是为什么呢？因为，有性能更好的树来做搜索！目前大部分数据库系统及文件系统都采用B-Tree或其变种B+Tree作为索引结构。 一、B-树和B+树回顾 1.B-树 B-tree （多路搜索树）是一种常见的数据结构。使用B-tree结构可以显著减少定位记录时所经历的中间过程，从而加快存取速度。按照翻译，B 通常认为是Balance的简称。这个数据结构一般用于数据库的索引，综合效率较高。 B-树每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。 B-树的特征： 根节点至少有两个孩子 每个非根节点有[ ,M]个孩； 每个非根节点有[ -1,M-1]个关键字，并且以升序排列 key[i]和key[i+1]之间的孩子节点的值介于key[i]、key[i+1]之间 所有的叶子节点都在同一层 B-树的优势： B树的优势在于多路查找，这便是优于红黑树的具体原因，大家想一想，B-树每个结点有多个key

概述 热点数据通俗的讲是指被高频使用到的数据，比如某些热点事件，由于网络的发酵效应，短时间能够达到几十万甚至上百万的并发量，针对这类场景，我们需要分析系统瓶颈所在，以及应对的技术实现 方案讲解 大并发架构演进 1、图1和图2的区别是中间会有一层web缓存服务器，该服务它可以由nginx+lua+redis进行设计完成，缓存层的热点数据分散，将会在后续的‘高并发度’章节做介绍。 2、热点数据肯定能在web层的缓存服务器被拦截住，防止把大量的请求打到应用服务器，但是对于非热点的数据穿透缓存后会请求至DB，这部分数据每秒几千的QPS对DB造成的压力也是非常大的，这个时候我们需要一定的方案，保证请求的时效性，就是如何降低DB层面的IO次数 场景分类 热点数据并发分为读和写两种场景，日常高并发遇到的大多数都是读场景，无论是采用何种的架构设计，都需要在缓存层和DB层面做热点数据的分散，本章着重介绍后者 原理分析 大家都知道对热点数据分散后，系统的性能会有显著提升，是什么原理导致的，接下来我们探讨一下db存储的一些关键知识，上面两个是大家经常用到的两种mysql存储引擎，尤其是后者，基本上笔者在工作中遇到的绝大多数的表都定义成了innodb引擎，两者的差异在哪里？使用场景的区别在什么地方？ 1、读数据 myisam ：与innodb一样都采用BTREE实现，myisam是非聚集索引

表 存储引擎种类： MyISAM结构： .frm文件：存储表数据定义、表结构 .MYD文件：存储表数据行 .MYI文件：存储表的索引，存储在b+tree里面 MyISAM存储引擎结构： 根据col=49，根据b+tree快速定位到49，获取磁盘指针（values） 0X90 ，从而获取表数据； InnoDB结构存储引擎：必须需要有主键，为啥？ .ibd文件：索引文件和 数据行合并 MyISAM和InnoDB 区别： MyISAM： 索引所在磁盘指针 InnoDB： 索引所在行其他字段存储 聚集索引：索引和数据在一起 非聚集索引：从一个文件去获取另一个文件，索引和数据没有在一起 问题： InnoDB结构存储引擎：必须需要有主键，为啥？ 如果InnoDB表没有主键，mysql会从表中寻找一个可以唯一标识的主键， 如果找不到，他会生成默认列（隐藏列）。来维护数据。 UUID：长串字符串，占有存储空间，比较慢等 为何使用自增主键？ 后面大于前面，一次追加，满足叶子节点 联合索引的底层结构： 小的放左边，相同的比较下面的参数。 来源： https://my.oschina.net/u/3915790/blog/3102123

阿里妹导读 ：任何应用系统都离不开对数据的处理，数据也是驱动业务创新以及向智能化发展最核心的东西。数据处理的技术已经是核心竞争力。在一个完备的技术架构中，通常也会由应用系统以及数据系统构成。应用系统负责处理业务逻辑，而数据系统负责处理数据。本篇文章主要面向数据系统的研发工程师和架构师，希望对你有所启发。 前言 传统的数据系统就是所谓的『大数据』技术，这是一个被创造出来的名词，代表着新的技术门槛。近几年得益于产业的发展、业务的创新、数据的爆发式增长以及开源技术的广泛应用，经历多年的磨炼以及在广大开发者的共建下，大数据的核心组件和技术架构日趋成熟。特别是随着云的发展，让『大数据』技术的使用门槛进一步降低，越来越多的业务创新会由数据来驱动完成。 『大数据』技术会逐步向轻量化和智能化方向发展，最终也会成为一个研发工程师的必备技能之一，而这个过程必须是由云计算技术来驱动以及在云平台之上才能完成。应用系统和数据系统也会逐渐融合，数据系统不再隐藏在应用系统之后，而是也会贯穿在整个业务交互逻辑。传统的应用系统，重点在于交互。而现代的应用系统，在与你交互的同时，会慢慢地熟悉你。数据系统的发展驱动了业务系统的发展，从业务化到规模化，再到智能化。 业务化：完成最基本的业务交互逻辑。 规模化：分布式和大数据技术的应用，满足业务规模增长的需求以及数据的积累。 智能化：人工智能技术的应用，挖掘数据的价值

问题：SQL查询慢怎么办？ 优化手段，加索引。 索引是 帮助MYSQL高效的获取数据的 排好序 的 数据结构。 问题：索引结构为什么使用Btree而不使用二叉树，红黑树或者HASH结构？ 二叉树的特性，右边子节点的值大于父节点，且左边子节点的值小于父节点 二叉树：使用二叉树来做索引的数据结构，当索引值递增的时候，二叉树也会不断地增加右子节点 ，那么在查找索引的时候，所做的IO操作，等同于没有索引逐行查找数据的IO操作。 红黑树：平衡二叉树。随着数据量增大，树的高度也会变高。2的N次方=数量量（假设100万），那么N至少也是50，那么树的高度也是50，如果数据在子叶节点上，那么至少要经过50次的IO操作，才能找到数据。 HASH：散列表结构，key不适合排序，而且数据是散列的分布的，不利于IO读写。 BTree：一个节点上，横向扩展。即一个节点上，可以存储多个元素（Degree），且每个元素，都可以有子节点，叫做多叉树。 度（Degree）-节点的数据存储个数 叶节点具有相同深度 叶节点的指针为空 节点中的数据KEY从左至右递增排列 以5阶B树举例 B+Tree（Btree变种） 非叶子节点不存储data，只存储key，可以增大度（Degree）-节点的数据存储个数 叶子节点不存储指针 叶子节点增加了顺序访问指针，提高区间访问的性能 以5阶B+树举例 问题：Btree和B