MySQL索引设计与选择

【MySQL系统架构设计】
【MySQL索引设计与选择】
【MySQL事务底层原理】

一、索引

在日常生活中，存在很多用到“索引”的地方，比如中华字典目录，图书馆分类，一本书籍目录，等待。那什么是索引？

索引是一种用于快速查找的数据结构。

索引是一种数据结构，那选择什么样的数据结构来构建索引呢？ 数据结构的选择，无非就是查找算法的选择，可以从两个维度来进行权衡：时间复杂度 和 空间复杂度。常见的非O(n)数据结构有：

• 二次查找树：左子节点永远小于父节点，右子节点永远大于父节点。
• 平衡二叉查找树：一种结构平衡的二叉搜索树，即叶节点高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树。
• Hash表（红黑树）：一种特殊的平衡二叉查找树，比平衡二叉查找树多了一些规则，如：结点只能为红色或黑色；根节点必须为黑色；所有叶子节点都是黑色(包括NIL节点)；每个红色结点的两个子结点都是黑色(从每个叶子到根的所有路径上不能有两个连续的红色结点)；从任一节结点到其每个叶子的所有路径都包含相同数目的黑色结点；关于红黑树的详细分析，可以参照《带你认识红黑树》。
• B Tree：多路平衡查找树，通常用于数据库和操作系统的文件系统中。有较高的查找效率，但是插入、删除需要对节点进行分裂、合并、转移等操作，效率较低。
• B+ Tree：一种特殊的B Tree，通常用于数据库和操作系统的文件系统中。有较高的查找效率，且插入、删除较为稳定。

2.4 B Tree（多路平衡查找树）

B-Tree 是一种自平衡的查找树，通常用于数据库和文件系统等需要高效地插入、删除和查找数据的应用中。B Tree 的名称中的“B”代表“平衡”（Balance），它的设计目标是确保树的高度保持平衡，从而保持快速的数据检索性能。下面是一个三路（分叉树）的平衡查找树。

可以看到 B Tree 具体以下特点：

1. 每个节点可以拥有多个子节点；
2. 从根节点到叶子节点的路径长度保持相对均衡；
3. 键值有序性：多路平衡查找树中的键值对通常按照一定的顺序存储，这有助于支持范围查询和有序遍历。
4. 路数（分叉数）永远比关键词数多 1；
5. 通过节点分裂和合并（当节点中的键值对数量达到一定阈值时，节点可能会分裂为两个节点，以保持平衡。相反，如果节点中的键值对数量减少，会将节点合并）来保持高度平衡；

上面的三路平衡查找树中，节点存储了两个键值（key-关键词，value-数据），三个指向子节点的指针，指针存储的是子节点所在磁盘块的地址。两个关键词划分成的三个范围域对应三个指针指向的子树的数据的范围域。以根节点为例，关键字为17和35，P1指针指向的子树的数据范围为小于17，P2指针指向的子树的数据范围为17~35，P3指针指向的子树的数据范围为大于35。

模拟查找关键字29的过程：

1. 根据根节点找到磁盘块1，读入内存。【磁盘I/O操作第1次】
2. 比较关键字29在区间（17,35），找到磁盘块1的指针P2。
3. 根据P2指针找到磁盘块3，读入内存。【磁盘I/O操作第2次】
4. 比较关键字29在区间（26,30），找到磁盘块3的指针P2。
5. 根据P2指针找到磁盘块8，读入内存。【磁盘I/O操作第3次】
6. 在磁盘块8中的关键字列表中找到关键字29。

分析上面过程，发现需要3次磁盘 I/O 操作，和3次内存查找操作。由于内存中的关键字是一个有序表结构，可以利用二分法查找提高效率。而3次磁盘 I/O 操作是影响整个 B-Tree 查找效率的决定因素。

B Tree的优势
相比于二叉树，B树的深度远远小于二叉树，所以查找效率远远大于二叉树

B Tree的弊端
B Tree在做检索时，检索效率非常高，但是在做数据插入和删除时，会破坏 B Tree 的平衡，所以需要对节点进行分裂、 合并、转移等操作，而这个操作在节点数量较多的情况下性能影响较大。所以这也是为什么我们在使用B Tree为索引数据结构时，索引的创建和更改性能较慢的原因。

2.5 B+ Tree

B+ 树是一种加强版多路平衡查找树。它的存储结构如下图所示：

B+ Tree 相比于 B Tree，主要优化点如下：

1. B Tree 的路数和关键字的个数的关系不再成立，数据检索规则采用的是左闭右开区间，路数和关键词个数关系为 1:1。
2. B+Tree 中只有叶子节点才存储数据，并且每个叶子节点都会增加一个指针指向相邻的叶子节点，形成一 个有序双向链表结构。

在B+ Tree数据结构下，模拟查找关键字29的过程：

1. 根据根节点找到磁盘块1，读入内存。【磁盘I/O操作第1次】
2. 比较关键字29在区间 [28，90)，找到磁盘块1的指针P2。
3. 根据P2指针找到磁盘块3，读入内存。【磁盘I/O操作第2次】
4. 比较关键字29在区间 [28，36)，找到磁盘块3的指针P1。
5. 根据P1指针找到磁盘块7，读入内存。【磁盘I/O操作第3次】
6. 在磁盘块7中的关键字列表中找到关键字29。

MySQL为什么最终要去选择B+Tree？

1. 它是B Tree的变种，B Tree能解决的问题，它都能解决。B Tree解决的 两大问题是什么？（每个节点存储更多关键字；路数更多）；
2. 扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵B+Tree拿到所有的数据）；
3. B+Tree的磁盘读写能力相对于 B Tree 来说更强（根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的键字更多）；
4. 排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链表）；
5. 效率更加稳定（B+Tree永远是在叶子节点拿到数据，所以IO次数是稳定的）；

三、MyISAM

在 MyISAM 存储引擎中，数据存储包括两个文件：

• .MYD文件：数据文件，D 表示 Data。
• .MyI文件：索引文件，I 表示 Index。

在MyISAM里面，索引和数据是两个独立的文件。 那我们怎么根据索引找到数据呢？实现机制如下图所示：

从MyISAM引擎中索引的实现来看，由于索引文件和数据文件是分离的，叶 子节点存储的是数据文件对应的磁盘地址，从索引文件.MYI中找到键值后， 会到数据文件.MYD中获取相应的数据记录。

注意：在MyISAM引擎中，主键索引和辅助索引在结构上没有任何区别。
只是主键索引要求key是唯一的，而辅助索引的key允许重复。

四、InnoDB

在InnoDB中，只有一个ibd文件，里面包含索引和数据。

同时，在B + Tree中的叶子节点存储了索引对应的数据行，所以我们称 InnoDB中索引即数据、数据即索引，它的整体结构如下图所示：

如上图中，叶子节点的数据区保存的就是真实的数据，在通过索引进行检索的时候，命中叶子节点，就可以直接从叶子节点中取出行数据。

4.1 聚簇索引和非聚簇索引

聚簇索引：所谓的聚簇索引，就是指索引键值的逻辑顺序和表数据行的物理存储顺序一 致。只有聚簇索引才会在叶子节点缓存表中的数据。在InnoDB中，组织数据的方式就是用聚簇索引组织表（Clustered Index Organize Table），所以一张表创建了主键索引，那么这个主键索引就是聚集索引。

非聚簇索引：除了主键索引以外，其他索引均属于非聚簇索引，非聚簇索引的叶子节点不 会存储表数据。

查询一个非聚簇索引的字段，怎么去获取到数据的值呢？

从上面这个图可以看到，真正的数据仍然是保存到主键索引的叶子节点（这也就是为什么InnoDB表必须要有主键的原因），而辅助索引的叶子节点的数据区保存的是主键索引的关键字的值（非主键索引叶子节点的逻辑顺序和磁盘顺序不一致）。

4.2 索引创建

1. 在用于where判断order排序和join的（on）、group by的字段上创建索引
2. 索引的个数不要过多：浪费空间，更新变慢
3. 区分度低的字段，例如性别，不要建索引：离散度太低，导致扫描行数过多。
4. 频繁更新的值，不要作为主键或者索引：B+树的平衡导致 页分裂 ，影响效率！
5. 随机无序的值，不建议作为索引，例如身份证、UUID：无序，分裂
6. 组合索引把散列性高（区分度高）的值放在前面
7. 创建复合索引，而不是修改单列索引！

4.3 索引失效

1. 索引列上使用函数（replace\SUBSTR\CONCAT\sum count avg）、表达式
2. 字符串不加引号，出现隐式的类型转化
3. like条件中前面带%
4. 负向查询：NOT LIKE 不能；!= （<>）和NOT IN 在某些情况下可以；

参考文献：
BTree和B+Tree详解