MySQL索引为什么用B+树不用B树

最新推荐文章于 2024-08-10 18:42:27 发布
原创 最新推荐文章于 2024-08-10 18:42:27 发布 · 3.8k 阅读 · 19 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#sql #mysql

本文详细解释了MySQL为何选用B+树而非B树作为索引结构的原因，包括B+树对随机和顺序检索的支持、更高的空间利用率、查询效率的稳定性和增删操作的效率优势。B+树通过叶子节点的指针实现数据的顺序遍历，且在磁盘IO性能和结构稳定性方面表现更优。

MySQL索引为什么用B+树不用B树

1.B树只适合随机检索，B+树支持随机检索和顺序检索

2.B+树空间利用率高，可以减少IO次数，磁盘读写代价更低。
一般来说索引本身也很大，往往以索引文件的形式存储在磁盘上，这样索引查找过程就要产生磁盘IO消耗。B+树的内部节点只作为索引使用，其内部节点（非叶子节点）比B树更小，判断能容纳的节点中关键字更多，一次读取到的键更多。

3.B+树查询效率更稳定，因为数据存放在叶子节点。

4.B树在一定程度上也提高了磁盘IO性能，但没有解决遍历效率低下的问题。B+树的叶子节点都使用指针顺序连接在一起，只要遍历叶子节点就可以实现所有值。

5.增删文件时，B树需要重新调整树结构。B+树不需要调整树结构，因此B+树效率更高。

被面试官虐了，索引为何使用B+树，你知道吗
a3961401的博客
09-09 2926
问题思考 数据库索引的数据结构有很多种，比如：哈希索引、平衡二叉树索引、B树索引、B+树索引等等。 目前最流行的是B+树索引，那大家有没有想过为什么是B+树索引最流行，为什么其他索引应用不广泛。 就像为什么别人能拿2-3万的工资，我却只能拿一万的工资，大家有思考过吗？ 哈希索引 hash大家应该非常的熟悉，就是我们老生常谈的HashMap里用到的技术。Hash索引其检索效率非常高，索引的检索可以一次定位。 推荐一个面试宝典，这份资料主要包含了Java基础，数据结构，jvm，多线程等等，有需要完整版的朋友可以
阿里三面：你跟我讲讲MySQL的B+树
wdjnb的博客
12-17 2203
大家好，我是小林。 大家背八股文的时候，都知道 MySQL 里 InnoDB 存储引擎是采用 B+ 是来组织数据的。 这点没错，但是大家知道 B+ 树里的节点里存放的是什么呢？查询数据的过程又是怎样的？ 这次，我们从数据页的角度看 B+ 树，看看每个节点长啥样。 InnoDB 是如何存储数据的？ MySQL 支持多种存储引擎，不同的存储引擎，存储数据的方式也是不同的，我们最常使用的是 InnoDB 存储引擎，所以就跟大家图解下InnoDB 是如何存储数据的。 记录是按照行来存储的，但是数
索引的原理：我们为什么用B+树来做索引？
m0_71777195的博客
10-29 763
本文总结了常见的树结构，我们主要关注BTree和B+Tree就可以了，其中B+Tree是BTree个改进版，二者的区别如下：在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息， 数据记录都存放在叶子节点中， 这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。在B+Tree上通常有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。
面试官：为什么 MySQL 索引要使用 B+树而不是其它树形结构？比如 B 树？
石杉的架构笔记
08-13 1940
公众号后台回复“学习”，获取作者独家秘制精品资料扫描下方海报二维码，试听课程：（课程详细大纲，请参见文末）来源：https://www.cnblogs.com/leefr...
mysql为什么不用b树_MySQL用B+树(而不是B树)做索引的原因
weixin_29563497的博客
01-19 4478
众所周知，MySQL的索引使用了B+树的数据结构。那么为什么不用B树呢？先看一下B树和B+树的区别。1.B树维基百科对B树的定义为“在计算机科学中，B树(B-tree)是一种树状数据结构，它能够存储数据、对其进行排序并允许以O(log n)的时间复杂度运行进行查找、顺序读取、插入和删除的数据结构。B树，概括来说是一个节点可以拥有多于2个子节点的二叉查找树。与自平衡二叉查找树不同，B-树为系统最优化...
MySQL 索引：索引为什么使用 B+树？
一蓑烟雨任平生
03-21 854
B 树中每个节点（包括叶节点和非叶节点）都存储真实的数据，B+树中只有叶子节点存储真实的数据，非叶节点只存储键。红黑树保证最长路径不超过最短路径的二倍，因而近似平衡（最短路径就是全黑节点，最长路径就是一个红节点一个黑节点，当从根节点到叶子节点的路径上黑色节点相同时，最长路径刚好是最短路径的两倍）：通过舍弃严格的平衡和引入红黑节点，解决了 AVL 旋转效率过低的问题，但是在磁盘等场景下，树仍然太高，IO 次数太多；从任一节点到其每个叶子的所有简单路径都包含相同数目的黑色节点（简称黑高）。
MySQL索引为什么使用B+树，而不用二叉树、红黑树、哈希表、B树？
折叠伞的博客
12-26 2487
索引是帮助MySQL高效获取数据的排好序的数据结构。 索引数据结构： 1.二叉树2.红黑树3.Hash表4.B-Tree。
mysql中为什么使用B+树作为索引
z3551906947的博客
08-10 1526
B树是一种自平衡的多路搜索树，用于数据库索引和文件系统。多路搜索：每个内部节点可以有多个子节点。键值分布：键值分布在内部节点和叶子节点，每个节点的键值将子节点分隔开。平衡性：B树在插入和删除操作中自动保持平衡。适用性：适用于读写操作，尤其是随机访问。B+树是B树的变体，专为数据库索引设计。所有数据在叶子节点：所有记录数据仅存储在叶子节点。非叶子节点仅存储键值：非叶子节点不存储实际的数据记录，只存储索引键和子节点的指针。叶子节点形成有序链表：叶子节点通过指针相连，便于范围查询和顺序访问。高扇出性。
mysql为什么要使用B+树作为索引
爪哇人的博客
02-21 7012
1 概述 大家可能在面试的时候都会被问到这样一个问题：mysql的索引结构是什么？这个时候了解的都知道是B+树，那么为什么会采用B+树作为它的索引结构呢？ 由图可以知道：索引的存在时为了加快数据访问提高查询效率的，而数据存储在磁盘中，但从磁盘读取数据会产生大量的IO操作，读取效率是非常低的。所以在读取的时候要减少io量和减少io次数来提高读取效率。 ...
MySQL面试：索引为啥使用B+树而不是B树
OceanStar的博客
10-21 2571
本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。 文章主要内容分为三个部分。 第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础。 第二部分结合MySQL数据库中MyISA.
MySQL为什么使用B+树，而不是B树？
jkzyx123的博客
06-15 4638
在MySQL中，B+树被广泛应用于索引结构，因为它支持高效的范围查询和区间扫描，并且有助于减少磁盘I/O操作，从而提高查询效率。B+树相对于B树来说，其内部节点只存储键值信息，而不存储数据信息，这样可以让每个节点能够存储更多的键值信息，从而使得查询同一层次的所有数据时，能够一次性读入更多的数据块，减少磁盘I/O操作。由于B+树的非叶子节点只存储键值信息，而不存储指向数据的指针，因此当进行范围查询时，只需要遍历B+树的叶子节点即可，而不需要遍历非叶子节点，大大加快了查询速度。
为什么MySQL索引要用B+树，而不是B树？
xmt1139057136的专栏
10-01 1382
一个面试题：InnoDB 一棵 B+ 树可以存放多少行数据？这个问题的简单回答是：约 2 千万。为什么是这么多呢？因为这是可以算出来的，要搞清楚这个问题，我们先从 Inn...
Mysql - 索引为什么使用B+树而不是B树
涛々的技术博客
11-29 5824
Mysql - 索引为什么使用B+树而不是B树
为什么MySQL索引选择B+树而不使用B树？
Java牛马的博客
10-06 1214
一般innodb索引层数有几层？解析：一般情况下，3-4层，因为3-4层的B+树足以支撑千万级别的数据存储；索引列的键(key)值怎么选？解析：innodb非叶子节点的存储是指针+键值，指针一般变化不大，所以索引列要尽可能选择占用空间小的字段，因为占用越小，单个节点能存储的 指针+键值 自然就更多，存储的数据自然就更多。创建表的时候，主键是否需要自增？
数据结构 -- 数据库的索引为什么要用B树或者B+树
Zystem
10-31 615
1、数据库索引 数据库的索引可以提高我们的查询速度，是存储在磁盘上的，但当数据量很大的时候，索引的大小可能有几个G甚至更多。当我们利用索引查询的时候，能把整个索引都加载到内存吗？显然是不可以的，能做的就是一次一次的加载磁盘页，这里的磁盘对应着所引述的节点。 索引树 磁盘页 如果索引采用二叉排序树，那么IO的最多次数就是取决于这个树的高度。 2、B树比二叉排序树快的原因 B树是一个多...
为什么MySQL InnoDB 存储引擎要用B+树做索引，而不用B树？
热门推荐
AI天才研究院
02-26 1万+
为什么MySQL InnoDB 存储引擎 要用B+树做索引，而不用B树？(1)B+树空间利用率更高，可减少I/O次数一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗。而因为B+树的内部节点只是作为索引使用，而不像B树那样每个节点都需要存储硬盘指针。也就是说：B+树中每个非叶节点没有指向某个关键字具体信息的指针...
【MySQL】数据库中为什么使用B+树不用B树
AliceNo的博客
12-26 4565
数据库索引是提高查询性能的关键因素之一，而在索引结构的选择中，B+树相对于B树更为常见和优势。本文深入探讨了为何数据库更倾向于使用B+树，详细解释了B+树相对于B树的优势。B+树通过有序叶子节点和链表结构，提供了更适合范围查询和顺序访问的特性，减少了磁盘IO次数，同时降低了非叶子节点的存储开销。这使得B+树在实际应用中更为高效，成为大多数数据库管理系统的首选索引结构。然而，索引结构的选择仍需根据具体应用场景和需求综合考虑，以实现最佳的性能和效率。深入理解B树和B+树的特性，有助于数据库开发者更好地进行索引设
MySQL 索引结构用B+树的原因
ChineseSoftware的博客
01-20 3304
MySQL 的基本存储结构是页(记录都存在页里边)： 各个数据页可以组成一个双向链表 每个数据页中的记录又可以组成一个单向链表 每个数据页都会为存储在它里边的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。 所以说，如果写select * from tab where name = 'xxx'这样没有进行任何优化的 sql 语句，默认会这样做： 定位到记录所在的页：需要遍历双向链表，找到所在的页。 从所在
mysql索引为什么用B+树的数据结构
最新发布
07-31
<think>嗯，用户想深入理解MySQL索引为什么采用B+树作为数据结构。这个问题在数据库领域非常经典，用户可能正在学习数据库索引原理，或是遇到了性能优化问题需要溯源。从用户连续追问索引结构的专注度看，应该是技术背景较强的开发者或DBA。 用户引用的四篇资料都聚焦在B+树的优势上，但角度各有侧重：引用[1]和[4]强调磁盘I/O优化，引用[2]对比了其他数据结构，引用[3]则点出存储引擎的实现差异。需要把这些信息整合成体系化的解释。 核心需要讲清楚三个层面的问题：首先是B+树本身的物理特性（树高、节点大小），然后是与其他数据结构的对比优势（特别是B树和哈希），最后要结合MySQL的存储设计（如InnoDB页机制）。用户之前的回复里已经提到过B+树三层能存1600万数据，这次可以补充计算过程。 特别要注意平衡理论和实践场景。比如不仅要解释“为什么适合”，还要说明“什么情况下优势会削弱”——例如当索引键过长时B+树深度增加，或是全内存场景下其他结构可能更优。用户似乎很关注技术决策的trade-off思维。 回复结构可以这样组织：先简述B+树结构特征，然后用对比表格突出其优势，最后补充实际应用时的注意事项。数学公式部分要完整呈现节点容量计算，但需用文字解释每个变量的含义。磁盘I/O次数与树高的关系需要重点说明，这是用户引用[1][2]反复提到的关键点。</think>MySQL 选择 B+ 树作为索引结构的核心原因在于其**卓越的磁盘 I/O 性能**和**对数据库查询场景的深度适配**。以下是关键原因分析： --- ### 一、B+树的核心优势 #### 1. **极低的磁盘I/O次数** - **节点容量大**： 每个节点存储大量键值（默认16KB页大小），大幅减少树的高度。 计算公式（以主键BIGINT为例）： $$ \text{单节点指针数} = \frac{16\text{KB}}{8\text{B（键值）} + 6\text{B（指针）}} \approx 1170 $$ $$ \text{三层树存储量} = 1170 \times 1170 \times 1170 \approx 1600\text{万行} $$ **仅需3次磁盘I/O即可检索千万级数据**[^1][^3]。 - **对比B树**： B树非叶节点存储数据，相同数据量下树高更高 → 更多磁盘I/O。 #### 2. **高效范围查询** ```mermaid graph LR A[范围查询] --> B[定位起始键值] B --> C[沿叶节点链表顺序扫描] C --> D[无需回溯父节点] ``` - 叶节点形成**双向链表**，范围查询（如`WHERE id BETWEEN 100 AND 200`）只需： 1. 定位起始键值（3次I/O） 2. 沿链表顺序读取（$O(1)$跳转） - **对比B树**：范围查询需回溯父节点，产生随机I/O。 #### 3. **数据存储优化** - **非叶节点不存数据**： 仅存储键值+指针 → 单节点容纳更多键值 → 进一步降低树高。 - **叶节点存储全集**： 所有数据均存于叶节点 → 查询路径长度稳定（$O(\log n)$）。 --- ### 二、与其他数据结构的对比 | **结构** | **范围查询** | **磁盘I/O** | **数据更新代价** | **适用场景** | |----------------|-------------|------------|-----------------|-------------------| | **B+树** | ✅ 极优 | ✅ 3层千万级 | 中（需平衡树） | 通用OLTP | | **B树** | ❌ 需回溯 | 树高更高 | 高（节点存数据） | 内存数据库 | | **哈希表** | ❌ 不支持 | $O(1)$ | 低 | 等值查询 | | **红黑树** | ✅ 支持 | $O(\log n)$| 高（旋转频繁） | 内存索引 | > ⚠️ **关键结论**： > - **磁盘型数据库**：B+树在I/O效率、范围查询、稳定性上全面占优[^1][^2] > - **内存型数据库**：哈希或红黑树可能更合适 --- ### 三、与MySQL架构的深度契合 #### 1. **适配InnoDB存储引擎** - **聚集索引**： 叶节点直接存储行数据 → 主键查询仅需1次检索[^3]。 - **辅助索引**： 叶节点存储主键值 → 更新数据时辅助索引无需修改。 #### 2. **页分裂优化** - 当叶节点满时（填充因子=15/16），触发页分裂： ```mermaid graph TB A[节点满] --> B[分配新页] B --> C[迁移50%数据] C --> D[更新父节点指针] ``` - **B+树分裂代价低于B树**： 数据仅存于叶节点 → 分裂不涉及非叶层数据迁移。 #### 3. **覆盖索引支持** - 联合索引`(col1, col2)`存储`col1值+col2值` - 查询`SELECT col1, col2`时**无需回表** → 直接返回索引数据。 --- ### 四、实际性能影响案例 ```sql -- 场景：1亿条用户数据查询 SELECT * FROM users WHERE age BETWEEN 25 AND 30; ``` - **B+树执行过程**： 1. 根节点→中间节点→定位首个age=25的叶节点（3次I/O） 2. 沿链表顺序扫描至age=30（顺序I/O，约5-10次） - **若用B树**： 每跳转一个节点需随机I/O → 预计20+次I/O（性能差5倍以上） --- > 💡 **设计启示**： > - **主键自增**：避免随机写入导致页分裂 > - **控制索引长度**：过长的键值会减少单节点键数量 → 增加树高 > - **覆盖索引优先**：减少回表查询的I/O开销
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值