MySQL —— 索引

索引的概念

MySQL的索引是种数据结构，它可以帮助数据库高效地查询、更新数据表中的数据。索引通过
定的规则排列数据表中的记录，使得对表的查询可以通过对索引的搜索来加快速度。

MySQL索引类似于书籍的目录，通过指向数据行的位置，可以快速定位和访问表中的数据，比如
汉语字典的目录（索引）页，我们可以按笔画、偏旁部首、拼音等排序的录（索引）快速查找到需
要的字。

探讨索引的数据结构

我们来一起探讨那种数据结构用来当作索引更适合数据库

首先是哈希表，对于哈希表来说，查找的时间复杂度为 O(1)，十分优秀，但是却不适合数据库，因为哈希表不支持范围查找，而我们数据库是需要支持范围查找的，例如：我们有张成绩表，要查询成绩大于等于60以上的学生时，这时就要求我们数据库能支持**范围查找，**所以哈希表并不适合作索引

---

接下来登场的是二叉搜索树，查找的时间复杂度为O(logN)，但是如果出现极端情况，二叉搜索树是可能会退化成一颗单分支的树，这时候时间复杂度就变成O(N)，还是不理想，这时候大家可能会想到AVL树或者红黑树，AVL树就不说了，旋转次数太多了，在数据库面前，数据量十分庞大，如果旋转，呵呵…
我们来看一下红黑树，虽然保持相对平衡，但是在数据一多的情况下，我们无法保证树到底有多高

为什么要讨论树高呢？
因为数据库的数据是存储在磁盘上的，所以当你需要读取数据的时候，是需要进行磁盘的IO的，磁盘的IO速度是十分慢的，如果IO 次数一高，效率就会低下哎，所以我们应该减少磁盘IO次数，也就是减小树高，那么红黑树就不能满足了

磁盘IO 是制约数据库性能的主要因素

---

既然红黑树不行，那我们可以考虑B树，这时一颗多路平衡树，由于是多路，所以可以降低书高，但是我们的MySQL还是不满意，觉得效率还不是不够高，于是MySQL 就使用B树的变形也就是B+树，我们在前面就知道B+树有一些特点：真实的数据都是保存在叶子节点上的，非叶子结点只是起到一个导航的作用，并且叶子结点是使用双向链表进行连接的，所以在数据库进行范围查找的时候十分方便。

B树示例：

B+树示例：

B+树的时间复杂度是O(logN)，并且可以有效的控制树高

B+树与B树的对比：
1.B+树的叶子结点之间有相互连接的引用，可以通过这个连接找到与其相邻的兄弟节点，mysql 在组织叶子结点时使用的时双向链表
2.非叶子结点的值包涵在叶子结点中，MySQL 非叶子结点只保存了对子结点的引用，没有保存真实的数据，所有真实的数据都是在叶子结点中
3.对于B+树而言，在相同书高的情况下，查找任意元素的时间复杂度都是一样的，性能均衡。

MySQL的页

在 .ibd 文件中最重要的结构体是 Page(页)，页是内存与磁盘交互最小单元，默认大小是 16KB

每一个.ibd 文件由页组成

每次内存与磁盘的交互至少读取一页，所以在磁盘中每个页内部的地址都是连续的，之所以这么做，是因为在使用数据的过程中，根据局部性原理，将来要使用的数据大概率与当前访问的数据在空间上是临近的所以一次从磁盘中读取一页的数据放入内存中，当下次查询的数据还在这个页中的时候，就可以直接从内存中读取，从而减少磁盘IO，以此来提高性能。

局部性原理：
是指程序在执行时呈现出局部性规律，在一段时间内，整个程序的执行仅限于程序中的某部
分。相应地，执行所访问的存储空间也局限于某个内存区域，局部性通常有两种形式：时间局部
性和空间局部性。
时间局部性（Temporal Locality）：如果个信息项正在被访问，那么在近期它很可能还会被再
次访问。
空间局部性（Spatial Locality）：将来要用到的信息大概率与正在使用的信息在空间地址上是临
近的。

每一个页中即使没有数据也会使用 16KB 的存储空间，同时与索引的B+树中的节点对应

我们可以查询MySQL中页的大小：