MySQL —— Innodb 索引数据结构

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

#mysql #数据结构 #数据库 #innodb索引数据结构

文章目录


MySQL 使用 B+树索引数据结构（因为默认使用 innodb 存储引擎）

  • B树：有序数组 + 平衡多叉树；
  • B+树：有序数组链表 + 平衡多叉树；

不用平衡二叉树或红黑树作为索引

普通二叉树：

  • 二叉树的查找的时间复杂度是 O ( l o g 2 N ) O(log_2N) O(log2​N)，其查找效率与深度有关，而普通的二叉树可能由于内部节点排列问题退化成链表。例如，按顺序插入一组递增的数值，可能导致树变成一条链表，在这种情况下，树的深度变为 N，查找的时间复杂度退化为 O ( N ) O(N) O(N)，这与链表的查找效率相同。这样查找效率就会很低。
    1
 \
  2
   \
最低0.47元/天 解锁文章
MySQL——索引类型与InnoDB索引
庄小焱
12-10 649
在日常工作中会经常接触到。比如某一个 SQL 查询比较慢，分析完原因之后，你可能就会说给某个字段加个索引吧之类的解决方案。但到底什么是索引，索引又是如何工作的呢？一句话简单来说，索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。一本 500 页的书，如果你想快速找到其中的某一个知识点，在不借助目录的情况下，那我估计你可得找一会儿。同样，对于数据库的表而言，索引其实就是它的“目录”。
【深入理解MySQL的索引数据结构】
我是Java程序员廖志伟，感谢朋友们的支持！
05-12 674
我出书啦！！！《Java项目实战——深入理解大型互联网企业通用技术（基础篇）》（计算机技术开发与应用丛书）
Mysql进阶索引篇02——InnoDB存储引擎的数据存储结构
m0_67401545的博客
06-08 302
前面我们已经剖析了mysql中与索引的数据结构，了解了B+树的设计思想、原理，并且介绍了B+树与、、、等的区别和实际应用场景。页和页之间并不一定在物理上相连，只是在逻辑上使用双向链表关联。指针、记录究竟是如何存储的呢？其实这就需要联系我们之前提到的行格式了。数据查找在页目录中二分法快速定位到槽，上面的过程都与页的内部结构相关，本文将详细的阐述。 这篇文章将对InnoDB引擎的数据存储结构介绍，带大家熟悉数据库的页的存储结构与行格式，为之后的调优做准备。索引实际上是存储在文件上的，确切的说是存储在页结构中的
深入解析MySQL InnoDB索引数据结构
boydoy1987的专栏
08-20 759
在数据库系统中，索引是提高查询效率的关键技术。MySQL InnoDB存储引擎采用了一种高效的数据结构——B+树，来管理和维护索引。本文将深入剖析InnoDB索引的数据结构，并分享一些实用的优化技巧。聚集索引（Clustered Index）二级索引（Secondary Index）全文索引（Full-Text Index）本文主要讨论聚集索引和二级索引的数据结构。本文介绍了MySQL InnoDB存储引擎的索引数据结构，并通过代码示例展示了B+树索引的构建过程。
MYSQL-INNODB索引构成详解
lizi88888的博客
10-09 1170
对于MYSQL的INNODB存储引擎的索引，大家是不陌生的，都能想到是 B+树结构，可以加速SQL查询。但对于B+树索引，它到底“长”得什么样子，它具体如何由一个个字节构成的，这些的基础知识鲜有人深究。本篇文章从MYSQL行记录开始说起，层层递进，包括数据页，B+树聚簇索引，B+树二级索引，最后在文章末尾给出MYSQL索引的建议。文章涉及较多基础知识，内容较为枯燥，因此采用较多的图片补充说明，希望能对读者有帮助。
mysql innodb 索引文件结构
痴迷无限好
10-30 399
mysql innodb 索引文件结构 http://blog.youkuaiyun.com/u012978884/article/details/52416997
Mysql InnoDB 索引结构
凡夫编程
11-23 3541
索引的本质是让mysql以最高效、扫描行数最少的方式找到需要的数据。索引作用很大，但是也不索引越多，查询性能就越高。同样索引太少，也不行。所以如何给应用程序创建合适的索引至关重要。我认为最好的方式，是根据业务发展的需要，可以动态的对创建索引进行调整。如业务初期数据量不多的时候，可以先不建索引，待业务增速比较快的时候，对查询的需求增多的时候，可以根据具体的业务场景的数据流进行创建或者调整。当然，如果可以提交预判业务上的查询需求，可以在初期的时候把索引创建好。创建合适的索引也是非常有技术含量的。
MySQL——Innodb存储引擎的索引原理详细解读
weixin_41438466的博客
09-30 474
0 前言 回想大二上数据库应用，老师在讲索引的时候，是像下面这么说的 索引就像一本书的目录。而当用户通过索引查找数据时，就好比用户通过目录查询某章节的某个知识点。这样就帮助用户有效地提高了查找速度。所以，使用索引可以有效地提高数据库系统的整体性能。 索引的优缺点 优势：可以快速检索，减少I/O次数，加快检索速度；根据索引分组和排序，可以加快分组和排序； 劣势：索引本身也是表，因此会占用存储空间，...
innodb存储引擎之：索引的数据结构（B+TREE）
三易专栏
08-25 452
什么是 目录项 每个页对应一个目录项，每个目录项包括下面两个部分 页的用户记录中最小的主键值，用 key 来表示 页号，用 page_no 表示 主键索引结构示意图 二级索引结构示意图 联合索引结构示意图 InnoDB 中 B+ 树索引的注意事项 根节点千年不动窝 一个 B+ 树索引的根节点自创建之日起便不会再移动(也就是页号不再改变)。这样只要我们对某个表建立一个索引 ，那么它的根节点的页号便会被记录到某个地方，后续凡是 InnoDB 存储引擎需要用到这个索引时，都会从那个固定
MySQL InnoDB存储引擎中的索引结构解析
一名后端程序猿
12-14 1858
在数据库系统中，索引是优化查询性能的关键技术之一。为了理解为什么MySQL的InnoDB存储引擎使用B+树而非其他数据结构，我们需要首先掌握各种数据结构的基本特性。
mysql之innodb索引结构
yxkong的专栏
08-10 502
前一篇，mysql之innodb存储结构我们了解了mysql的innodb的存储结构。这次我们再来了解innodb的索引结构；在上一篇中我们说到record_type 有4种属性，其中1表示目录项记录，这次我们重点讲的就是这个。存储结构上一篇讲解的时候只是在强调InnoDB的数据页。在页之上有段，段之上有区，之前在讲undo log的时候也强调过这个概念。借用一张图 表空间（table space）表空间（Tablespace）是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段
MySql InnoDB索引实现原理，带你彻底搞懂索引数据结构
qq_43100194的博客
01-26 325
MySql InnoDB索引实现原理，带你彻底搞懂索引数据结构 先来了解一个概念：Innodb_page_size，这是Innodb在存取数据时，最小的基本单位，可以理解为"一页"，默认大小为16KB，Innodb每次向磁盘存取数据时，最小存取一页数据，即16KB数据，这样做的好处是：可以有效减少IO操作，提高性能； 先来看一眼 “页” 的结构： 看上去可能有点儿蒙，没关系，暂时只需要知道有这么个东西，由图可知，“页”中包含“页目录”和“用户数据区域”； 先来举个例子，建立一张表，如下图： 此时，这张
数据结构索引-InnoDB索引
伽蛙的专栏
05-26 1560
我们知道，MyISAM索引文件和数据文件是分离的，索引文件仅仅保存了数据记录的地址。 在InnoDB中，数据文件本身就是索引文件，表文件本身就是一个按照B+树组织的一个索引结构，叶节点data保存了完整的数据记录，这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。      上图是InnoDB数据文件（主索引）的示意图，叶节点包含了所有
【MySQL】三、InnoDB索引结构和原理
会飞的猴儿
11-11 1812
简单介绍InnoDB的主键索引和二级索引的基本结构，以及如何利用索引进行查询的，包括回表和索引覆盖的概念等
mysql innodb 索引结构_mysql innodb索引结构及相关原理-Go语言中文社区
weixin_26911099的博客
02-01 161
最近在优化线上代码，优化过程中，对数据库进行了一系列的学习和基础巩固，看了很多大佬写的文章，整理了一下，记录在这里～参考文档：B+tree的结构页在操作系统中，当我们往磁盘中取数据的时候，如果我们想要取出1kb的数据时，会发现，操作系统取出了4kb的数据，这是因为操作系统中页的大小是4kb。这是为什么呢？当一个程序访问了一条数据之后，很有可能在此访问这条数据或访问这条数据相邻的数据。因此，干脆直接...
mysql innodb 索引结构_InnoDB表与索引结构相关知识整理
weixin_31600859的博客
01-27 207
MySQL把表的数据词典信息以.frm文件的形式存在数据库目录里，所有MySQL存储引擎都是这样的。但是每个InnoDB表在表空间内的InnoDB内部数据词典里也有它自己的条目。当MySQL移除表或数据库，它不得不删除.frm文件和InnoDB数据词典内的相应条目。这就是为什么你不能在数据库之间简单地移动.frm文件来移动InnoDB表。1. 聚集索引和第二索引每个InnoDB有一个叫聚集索引(c...
mysql默认存储引擎的索引结构是_InnoDB引擎的索引和存储结构
weixin_39610724的博客
01-28 500
在Oracle 和SQL Server等数据库中只有一种存储引擎，所有数据存储管理机制都是一样的。而MySql数据库提供了多种存储引擎。用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据自己的需要编写自己的存储引擎。1.MySQL主要存储引擎的区别MySQL默认的存储引擎是MyISAM，其他常用的就是InnoDB，另外还有MERGE、MEMORY(HEAP)等。(1)主要的几个存储引...
mysql innodb索引结构及相关原理
一只路过的小码农cxy
12-30 593
最近在优化线上代码，优化过程中，对数据库进行了一系列的学习和基础巩固，看了很多大佬写的文章，整理了一下，记录在这里～ 参考文档： 清空认知，然后重新理解MySQL索引结构 MySQL索引背后的数据结构及算法原理 B+tree的结构 页 在操作系统中，当我们往磁盘中取数据的时候，如果我们想要取出1kb的数据时，会发现，操作系统取出了4kb的数据，这是因为操作系统中页的大小是4kb。这是为什么...
006 mysql之InnoDB索引结构
weixin_41717359的博客
12-26 305
文章目录前言主键索引（聚簇索引）二级索引 前言 InnoDB索引使用的是B+树。 索引分为：主键索引和非主键索引（二级索引） 主键索引（聚簇索引） InnoDB通过主键聚集数据，下图中被索引的列就是主键。 聚簇索引优点： 聚簇索引缺点： 二级索引 下面是InnoDB和MyISAM索引的结构： ...
mysql的后台索引数据存储结构
最新发布
07-31
<think>嗯，用户这次想深入了解MySQL索引的存储结构，看来是个认真钻研技术细节的人。从ta引用的资料来看，已经对B+树、聚集索引等概念有基础了解，现在需要更系统的解析。 用户可能正在做数据库性能优化，或者准备面试。ta引用的三篇资料质量不错，特别是第三篇提到磁盘页16KB设计对树高的影响，这个点很关键。我需要在回答中强化这个计算过程：1170个子节点 * 1170 * 1170 ≈ 1600万数据只需3层，这个数字要具体化。 注意到用户特别标注“后台”索引存储，说明需要区别于表层原理的底层机制。考虑从四个维度展开： 1）物理存储层面：InnoDB的段/区/页结构（连16KB页内行记录格式都可以提） 2）数据结构层面：B+树节点如何映射到磁盘页 3）引擎差异：重点对比InnoDB和MyISAM索引存储的物理文件差异 4）动态维护：B+树分裂合并时页的分配机制 用户引用的资料2提到辅助索引回表机制，这个在回答里要图解化。可以用mermaid展示辅助索引→主键索引→数据行的三级跳过程，比文字描述直观。 需要警惕的是不能简单堆砌概念。比如解释“为什么非叶节点不存数据”时，要关联到磁盘预读原理：16KB页只存键值能容纳更多节点，把“减少IO次数”这个核心价值说透。 最后补充的注意事项里，关于页分裂的代价要具体。比如自增主键插入是顺序写，而UUID插入可能导致50%的页分裂率——这种量化表达比单纯说“性能更好”更有说服力。</think>### MySQL索引数据存储结构详解 #### 一、核心数据结构：B+树 MySQL索引采用**B+树结构**，这是专为磁盘存储设计的平衡多路搜索树： ```mermaid graph TD A[B+树节点] --> B[非叶节点] A --> C[叶节点] B --> D[存储索引键值+子节点指针] C --> E[存储数据] C --> F[双向链表连接] ``` 1. **节点设计** - **非叶节点**：仅存储索引键值+子节点指针（不存实际数据） - **叶节点**： - InnoDB：存储主键值+完整行数据（聚集索引） - MyISAM：存储行数据物理地址指针 - 所有叶节点通过双向链表连接 2. **磁盘优化设计** - 每个节点大小固定为**16KB**（`Innodb_page_size`） - 计算示例（主键为BIGINT）： $$ \text{单节点子节点数} = \frac{16\text{KB}}{8\text{B（主键）} + 6\text{B（指针）}} \approx 1170 $$ $$ \text{三层树存储量} = 1170 \times 1170 \times 1170 \approx 1600\text{万行} $$ - 百万级数据仅需**3次磁盘IO**即可定位[^3] > 💡 **B+树 vs B树** > - B+树数据全在叶节点 → 查询路径长度稳定 > - B树非叶节点存数据 → 树高更高，随机IO更多 --- #### 二、存储引擎实现差异 ##### 1. InnoDB（聚集索引） ```mermaid graph LR A[主键索引] --> B[叶节点存储完整行数据] C[辅助索引] --> D[叶节点存储主键值] D -->|回表查询| A ``` - **数据文件**：`.ibd`文件（索引与数据一体） - **主键索引**：叶节点直接存储行数据（物理有序） - **辅助索引**：叶节点存储主键值，需**二次查找** - **优势**：主键查询极快（1次检索获数据） ##### 2. MyISAM（非聚集索引） ```mermaid graph LR A[索引] --> B[叶节点存储行地址] B --> C[.MYD数据文件] ``` - **文件分离**： - `.MYI`：索引文件（B+树结构） - `.MYD`：数据文件（堆表） - **所有索引**：叶节点存储数据行物理地址 - **特点**：主键/非主键索引结构相同 --- #### 三、关键存储细节 1. **页内结构（InnoDB）** ```plaintext | 页头 (38B) | 虚记录 | 记录堆 | 自由空间链表 | | 未分配空间 | 槽区 | 页尾 (8B) | ``` - **行记录存储**：按主键顺序物理存储（插入时可能页分裂） - **槽（Slot）机制**：页内记录通过二分查找定位 2. **辅助索引存储** - 叶节点存储：`索引列值 + 主键值` - 优势： - 数据更新时辅助索引无需修改 - 支持**覆盖索引**（避免回表） 3. **联合索引存储** - 索引键按声明顺序拼接 `(col1, col2) → 存储值 = col1值 + col2值` - **最左匹配原则**： `WHERE col1=1 AND col2=2` ✅ `WHERE col2=2` ❌（无法使用索引） --- #### 四、性能关键指标 | **场景** | **存储影响** | **优化建议** | |-----------------|-------------------------------|---------------------------| | **范围查询** | 叶节点双向链表 → $O(1)$跳转 | 优先使用自增整型主键 | | **插入性能** | 随机主键导致页分裂（$O(\log n)$） | 避免UUID等随机主键 | | **空间占用** | 索引≈表数据20%-30%[^1] | 定期清理冗余索引 | | **更新代价** | 需更新所有相关索引 | 减少非必要索引 | > ⚠️ **页分裂代价** > 当叶节点满时（填充因子=15/16），触发页分裂： > - 新分配磁盘页 > - 迁移50%数据 > - 更新父节点指针 > 随机插入场景下可能产生**存储碎片** --- ```mermaid graph TD A[SQL查询] --> B{使用索引？} B -->|是| C[索引类型判断] C -->|主键索引| D[直接获取行数据] C -->|辅助索引| E[获取主键→回表查询] B -->|否| F[全表扫描] ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值