江苏龙网

  1. 主页 > 生活百科 > >

MySQL索引数据结构入门

mysql

之前松哥写过一个 MySQL 系列，但是当时是基于 MySQL5.7 的，最近有空在看 MySQL8 的文档，发现和 MySQL5.7 相比还是有不少变化，同时 MySQL 又是小伙伴们在面试时一个非常重要的知识点，因此松哥打算最近再抽空和小伙伴们聊一聊 MySQL，讲讲原理，讲讲优化，我会从最基本最简单的开始，和大家梳理 MySQL 中常见的面试知识点 。
本文我们就先从最简单的索引开始吧～
1. 什么是索引说到索引，最常见的例子就是查字典，当我们需要查询某一个字的含义时，正常操作都是先根据字典的索引，找到该字在哪一页，然后直接翻到该页就行了 。如果没有这个索引的话，那么我们就得一页一页的翻字典，直到找到该字 。很明显，相对于第一种方案，第二种方案效率就要低很多了 。
数据库中的索引也是类似的 。
索引，我们也称之为 index 或者 key，当数据量比较少的时候，索引对于查询产生的效果并不明显，所以索引常常被人所忽略，但是当数据量比较大的时候，一个优秀的索引对查询产生的影响就是非常明显的了 。在我们所掌握的各种 SQL 优化策略中，索引对 SQL 优化产生的效果算是最好的了，用好索引，SQL 性能可能会提升好几个数量级 。
这里有的小伙伴可能会有一个疑惑，很多索引优化策略都是针对传统的机械硬盘的，然而现在我们大部分都是固态硬盘（SSD），很多针对机械硬盘的优化策略在 SSD 上似乎并没有必要，那还有必要去考虑索引优化吗？答案当然是有！无论是用什么样的磁盘，索引优化的整体原则都是不变的，只不过在 SSD 上，如果你的索引没有创建好，那么它对查询的影响不像对机械硬盘那么糟糕 。
2. 索引的数据结构2.1 B+Tree 和 B-Tree小伙伴们知道，由于 MySQL 中的存储引擎设计成了可插拔的形式，任何机构和个人如果你有能力，都可以设计自己的存储引擎，而 MySQL 的索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎的索引工作方式都不一样，甚至，相同类型的索引，在不同的存储引擎中实现方案都不同 。
本文松哥主要和小伙伴们介绍我们日常开发中最最常见的 InnoDB 存储引擎中的索引 。
小伙伴们知道，InnoDB 存储引擎的索引数据结构是一个 B+Tree，至于什么是 B+Tree，这并非本文的重点，我这里不啰嗦，不了解 B+Tree 的小伙伴可以自行搜索一下学习一下 。
假设我有如下数据：
username
age
address
gender
ab
99
深圳
男
ac
98
广州
男
af
88
北京
女
bc
80
上海
女
bg
85
重庆
女
bw
95
天津
男
bw
99
海口
女
cc
92
武汉
男
ck
90
深圳
男
cx
93
深圳
男
现在我给 username 和 age 字段建立联合索引，那么最终数据在磁盘上的存储结构是 B+Tree，为了小伙伴能够更好的理解 B+Tree 和 B-Tree，我画了如下两张图：

MySQL索引数据结构入门

文章插图
这两张图看懂了，InnoDB 存储引擎的索引我觉得基本上都搞懂了 80% 了，松哥来和大家稍微梳理一下这张图：
  1. 首先这两张图都是一个多路平衡查找树，即，不是二叉树，是多叉树 。
  2. 绿色的方块表示指向下一个节点的指针；红色的方块表示指向下一个叶子节点的指针（B-Tree 中不存在该部分）；带阴影的矩形则表示索引数据 。
  3. B+Tree 非叶子节点只保存关键字的索引和指向下一个节点的指针（绿色区域），所有的数据最终都会保存到叶子节点 。因此在具体的搜索过程中，所有数据都必须要到叶子节点才能获取到，因此每次数据查询所需的 IO 次数都一样，这也就意味着 B+Tree 的查询速度比较稳定 。
如果是 B-Tree 则分支节点上也保存了指向具体数据的指针，并且分支节点上出现的索引数据不会再次出现在叶子节点中，所以搜索的时候可能搜索到分支节点就找到需要的数据了，搜索效率不稳定，如 af 在分支节点上就找到了，而 ac 则要到叶子节点上才能找到） 。


推荐阅读


上一篇：聊聊关于RoCE技术三种实现及应用

下一篇：边缘计算对数据中心管理的影响