MySQL——什么是索引？索引的底层结构是什么？

原创已于 2024-12-02 14:49:55 修改 · 277 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库

于 2024-05-26 15:34:37 首次发布

MySQL 专栏收录该内容

9 篇文章

订阅专栏

一、什么是索引？

索引是帮助数据库高效查找数据的一种数据结构，主要用于提高数据的检索效率，降低数据库的IO成本，同时通过索引列来排序，降低数据排序的成本以及CPU的损耗

二、索引的底层结构

MySQL采用的是InnoDB引擎，用的是B+树的结构来存储数据

1、B+树的介绍

1）B+树只有叶子节点存储数据，非叶子节点只存储指针

2）B+树是一个矮胖树，层级低查找效率高

3）叶子节点之间是以双向链表的形式存在的，便于扫库，和区间查询

2、B+树和B树的不同

1）B树的叶子结点非叶子节点都存储数据和指针而B+树只有叶子结点存储数据其他节点只存储指针查找的效率更稳定

2）B+树查找效率更高因为叶子结点是双向链表的结构，所以便于区间查询，和扫库

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

lemonMann

关注关注

2
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

【深入理解MySQL的索引数据结构】

我是Java程序员廖志伟，感谢朋友们的支持！

05-12

691

我出书啦！！！《Java项目实战——深入理解大型互联网企业通用技术（基础篇）》（计算机技术开发与应用丛书）

索引是什么？它的底层是怎么实现的？

ludan_xia的博客

04-21

2281

一、索引是什么？索引是单独的，物理的对数据库表中一列或多列的值进行排序的一种存储结构，让程序能够快速找到所需内容。索引是一种数据结构（平衡树非二叉），即B树，B+树，通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件。二、它的底层是怎么实现的？（一）B-树注意:之前有看到有很多文章把B树和B-tree理解成了两种不同类别的树，其实这两个...

参与评论您还未登录，请先登录后发表或查看评论

索引底层数据结构

heima201907的博客

03-06

782

.数据库简介 数据库官方描述：是一款用于存储的文件系统组成部分：文件系统 + 磁盘文件系统：文件管理机制、缓存系统、日志机制、SQL解析器、容灾机制、权限管理、索引模块、锁模块存储模块：机械硬盘、固态硬盘、磁盘阵列 2.IO的本质如图是磁盘的平视图 1.黑线：磁头 2.扇区: 磁盘上的每个磁道被等分为若干个弧段，这些弧段便是磁盘的扇区.扇区是磁盘最小的物理存储单元 3.磁道: 以盘片中...

mysql索引底层结构

码大师的博客

01-10

1226

Mysql索引优化 ---- 介绍 1、索引是什么 MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。可以得到索引的本质：索引是数据结构，索引的目的是提高查询效率，可以类比英语新华字典，如果我们要查询MySQL这个单词，首先我们需要在目录（索引）定位到M，然后在定位到y，以此类推找到SQL。如果没有索引呢，那就需要从A到Z，去遍历的查找一遍，直到找到我们需要的，一个一个找和直接根据目录定位到数据，是不是差的天壤之别呢，这就是索引的妙用。 2、索引底层数据结构 当数据

MySQL——各种索引结构的对比

万里顾一程的博客

02-22

1190

文章目录MySQL——各种索引结构的对比1、Hash结构2、AVL 平衡二叉搜索树3、B-Tree4、B+Tree MySQL——各种索引结构的对比 1、Hash结构 Hash 被称为散列函数，是把任意长度的输入通过散列算法变换成固定长度的输出，该输出就是散列值。不同的输入可能会散列成相同的输出，所以不可能从散列值来确定唯一的输入值。 Hash 函数它可以帮助我们大幅提升检索数据的效率。 Hash 算法是通过某种确定性的算法（比如MD5、SHA1、SHA2、SHA3）将输入转变为输出。相同的输入永远可以得

MYSQL——MYSQL中索引的底层结构

weixin_42924812的博客

11-23

215

MYSQL中索引的底层结构 首先，让我们搞清楚“树”这种数据结构。参考文章链接： MySQL索引底层实现原理

MySQL索引数据结构底层（全）

热门推荐

緑水長流*z

08-07

1万+

一、索引概述索引是帮助数据库快速查询数据的一种数据结构，在数据库中，数据库系统除了存储数据之外还维护着一种特殊的数据结构，这种数据结构以某种方式指向数据，这样就可以在这种数据结构上实现高级算法来查询数据，这种数据结构就是索引。索引是啥？索引就是帮助我们快速查找数据的一种数据结构！没毛病！索引示意图：我们来直观的感受一下，有建立索引和没有建立索引的直观感觉如图所示，索引能够帮我们快速的定位到数据的具体位置，高效查询。一般来说，索引本身也很大，不可能全部存储在内存当中，因此索引往往以索引文件

MySQL——图文版搞懂MySQL的索引是什么？

xdx_dili的博客

10-19

768

MySQL——图文搞懂MySQL的索引按数据结构分类可分为：B+tree 索引、 Hash 索引、 Full-text 索引。按物理存储分类可分为：聚簇索引(主键索引)、二级索引（辅助索引）。按字段特性分类可分为：主键索引、普通索引、前缀索引。按字段个数分类可分为：单列索引、联合索引（复合索引、组合索引）。

什么是 MySQL 索引?

allen的博客

03-25

5731

什么是索引？假设我们有一张数据表 employee(员工表)，该表有三个字段（列）,分别是name、age 和address。假设表employee有上万行数据(这公司还真大），现在需要从这个表中查找出所有名字是‘ZhangSan’的雇员信息，你会快速的写出SQL语句： select name,age,address from employee where name='ZhangSan...

Mysql——索引的底层数据结构与算法

weixin_45682305的博客

02-24

216

Mysql索引的底层数据结构与算法。

Mysql索引底层数据结构.pptx

04-24

MySQL索引底层数据结构是数据库性能优化中一个核心概念，其涉及的原理与技术点对于数据库的查询优化至关重要。索引可以显著加快数据检索速度，减少查询时间，但同时也可能增加写入操作的时间和空间开销。理解索引的...

【MySQL】深入理解MySQL索引底层数据结构与算法

金鳞踏雨

09-29

2810

索引是帮助MySQL高效获取数据的的。排好序这三个字其实就是对索引最好的形容和体现。我们可以简单把索引比喻成为书本的目录页，当然这么说太过于抽象，并没有把索引的底层特性说明白，下面我们将依次分析这些数据结构，来说明索引究竟是什么？！

数据库索引——B+树索引（为什么使用B+树作为MySql的索引结构，用什么好处？）

your_棒棒糖的博客

05-12

1611

数据库索引——B+树索引索引是一种数据结构，用于帮助我们在大量数据中快速定位到我们想要查找的数据。索引最形象的比喻就是图书的目录了。注意这里的大量，数据量大了索引才显得有意义索引在 MySQL 数据库中分三类： B+ 树索引 Hash 索引全文索引 B+树索引 B+树进化具有的优点：索引节点没有数据，比较小，能够完全加载到内存中而且叶子节点之间都是链表的结构，所以B+Tree也是可以支持范围查询的，而B树每个节点key和data在一起，则无法区间查找 B+树中因为数据都在叶子节点，每次查询

MySQL——索引与EXPLAIN

等一杯咖啡的博客

12-05

1526

前言本文内容主要参考自《高性能MySQL》第5章以及《MySQL DBA 修炼之道》书中的第三章，算是原书的实践与补充。上次主要讲了MySQL的基本操作，这次来谈谈索引与EXPLAIN。 I. 什么是索引？想要深入的学习MySQL相关技术，而不仅仅停留在简单CURD，能够写出百万数据中分分钟查出需要数据的SQL，首先就需要掌握索引技术。那么什么是索引呢？要理解MySQL中索引是如何工作的，...

MySQL 的锁类型有哪些

最新发布

2301_80096362的博客

12-08

213

摘要：数据库锁机制根据锁定粒度分为全局锁、表级锁和行级锁。全局锁锁定整个数据库实例，适用于全库备份；表级锁包括表锁和元数据锁（MDL），MDL自动管理表结构变更的并发控制；行级锁针对单行记录，并发度高但开销大。三种锁在锁定粒度、开销、加锁速度和并发度上各有特点，适用于不同场景，如全局锁用于备份，表级锁用于DDL操作，行级锁用于高并发事务更新。

NineData社区版V4.7.0发布！新增MySQL至TiDB等6条数据复制对比链路，SQL窗口新增谷歌云6种数据源类型

云原生智能数据管理平台

12-05

998

NineData社区版V4.7.0正式发布，新增6条数据复制链路（包括MySQL至OceanBase/TiDB等5条跨源链路和1条同构链路），均支持全流程数据同步与对比功能。同时新增6种谷歌云数据源支持，优化了MongoDB内网复制和MySQL XA事务性能。该版本现已支持27种数据库迁移链路，提供包括SQL审核、结构设计等企业级DevOps能力。作为免费开源工具，NineData社区版支持Docker快速部署，具备高性能CDC同步技术，适用于数据库迁移、容灾、ETL等场景，5-10分钟即可完成安装体验。

mysql_mcp_server部署及应用案例

runfarther的专栏

12-05

238

本文介绍了在CentOS 7.5系统下安装和部署mysql_mcp_server的完整流程。主要包括三个部分：1）服务安装步骤，包括源码下载、创建独立Python环境及安装依赖包；2）服务配置方法，涉及创建配置文件、设置监听端口和MySQL数据库连接参数；3）服务启动命令。整个过程详细说明了从环境准备到服务运行的全套操作，为在CentOS系统上部署该MySQL管理服务提供了清晰的指导。

mysql运维（日志）

weixin_74390886的博客

12-03

267

慢查询日志记录了所有执行时间超过参数long_query_time设置值并且扫描记录数不小于min_examined_row_limit的所有的sql语句的日志，默认未开启。可以使用log_slow_admin_statements和更改此行为log_queries_not_using_indexes。查询日志中记录了客户端的所有操作语句，而二进制日志不包含查询数据的sql语句。在二进制日志记录了所有的DDL(数据定义语言）语句和DML(数据操纵语言）语句，但不包括数据查询语句。

MySQL试验部署

Xyz996_的博客

12-04

253

1.1、关闭防火墙和selinux，进行时间同步添加配置文件登录g1数据库查看g2数据库同步给upload赋予apache权限

索引层级大于4为什么建议重建索引？

12-03

<think> 嗯，用户再次聚焦在索引层级大于4时重建索引的原因上，看来ta对数据库性能优化有实际需求。之前已经解释过高度和碎片化的关系，但用户可能更想了解背后的物理机制。用户引用的资料[2]提到“超过4层需要考虑重建”，这和主流数据库的最佳实践一致。不过要注意的是，MySQL的InnoDB引擎中索引高度计算方式比较特殊——它的B+树每层节点数更多，所以4层其实能支撑很大数据量（约$2000^4=16$万亿行）。真正需要警惕的是高度突然增加，比如从3跳到4，这往往意味着索引结构劣化。碎片化导致性能下降的原理值得展开：当删除数据时，索引节点会产生“空洞”，这些空洞不会被立即回收。查询时需要扫描更多无效节点，就像在布满坑洼的路上开车更费油一样。高度增加就是这种碎片化的外在表现。用户可能还隐含了一个疑问：为什么偏偏选4层作为阈值？这其实是经验值。在机械硬盘时代，每增加一层索引就需要一次磁盘寻道（约10ms），4层意味着40ms的纯寻道时间，超过这个阈值用户体验会明显下降。虽然现在SSD普及了，但阈值习惯保留下来。需要提醒用户的是，在云数据库场景下，自动索引维护已经很成熟。比如AWS RDS的自动重建机制就基于三个指标：碎片率>30%、高度突变、查询延迟恶化。用户如果使用托管服务，可以少操心这些。 </think>当数据库索引层级（高度）大于4时建议重建索引，主要基于以下核心原因，结合底层机制和性能影响分析： --- ### **一、根本原因：索引树深度直接影响查询性能** 1. **I/O操作成本指数级增长** 索引层级（高度）对应B+树从根节点到叶子节点的路径长度。层级每增加1，查询时需要多访问1个磁盘页（Page）。 - 若高度=4：查询需4次I/O（根→分支1→分支2→叶子） - 若高度=5：查询需5次I/O 由于磁盘I/O是数据库最耗时的操作，层级增加会导致**查询延迟显著上升**（尤其在机械硬盘场景）[^1]。 2. **索引高度超常增长的典型诱因** 正常情况下，B+树高度与数据量呈对数关系（$h \approx \log_m N$，$m$为节点容量）。当高度≥5时（常见阈值），通常意味着： - **索引碎片化严重**：频繁的DELETE/UPDATE导致叶子节点出现大量空洞，节点利用率降低，树被迫“虚高”[^2]。 - **数据分布失衡**：索引键值分布不均（如单调递增主键），导致树结构倾斜。 --- ### **二、重建索引的核心价值** 通过重建索引可解决以下问题： | **问题类型** | **重建后的改善** | |--------------------|----------------------------------------------------------------------------------| | **空间碎片整理** | 合并碎片化的叶子节点，提升节点填充率（减少空洞），降低树高度[^2] | | **数据分布优化** | 重新平衡B+树结构，避免倾斜分支（如`ALTER INDEX ... REBUILD`重组织数据物理顺序） | | **统计信息更新** | 强制刷新索引统计信息（如`ANALYZE TABLE`），帮助优化器生成更高效的执行计划 | > **典型案例**： > 若某索引原高度=5，碎片率>30%，重建后： > - 高度可能降至4（减少1次I/O） > - 碎片率降至<5% > 查询速度可提升20%~50%（取决于数据规模）[^2]。 --- ### **三、注意事项：何时不需重建？** 满足以下条件时，即使高度>4也无需重建： 1. **数据量极大是主因** 若表数据量达亿级，高度=4~5属正常范围（如InnoDB节点默认16KB时，高度=4可支撑约$2000^4=16$万亿行数据）[^1]。 2. **碎片率低且性能稳定** 通过命令检查碎片率（如MySQL中`SHOW TABLE STATUS`）： ```sql -- 检查碎片率 (Data_free表示碎片空间) SHOW TABLE STATUS LIKE 'table_name'; -- 若Data_free / Data_length < 0.2（20%），通常无需重建 ``` --- ### **四、操作建议：科学决策流程** ```mermaid graph TD A[监控索引高度≥5?] -->|是| B[检查碎片率] A -->|否| C[维持现状] B -->|碎片率≥20%| D[在低峰期重建索引] B -->|碎片率<20%| E[结合查询性能判断] E -->|查询延迟高| D E -->|性能正常| C ``` **重建命令示例（MySQL）**： ```sql -- 重建单索引 ALTER TABLE orders REBUILD INDEX idx_customer_id; -- 重建表所有索引 OPTIMIZE TABLE orders; ``` > **关键提示**： > - 重建索引会锁表（InnoDB支持Online DDL但仍可能影响性能） > - 优先在业务低峰期操作 > - 高度>4是**警示信号**，非绝对重建标准[^2] --- **结论**：索引高度>4时建议重建，**本质是解决因碎片化导致的“虚高”问题**，通过降低树深度减少I/O次数。但需结合数据量、碎片率和实际性能综合决策，避免过度优化。