MySQL为什么要使用B+树做索引？MySQL索引存储模型推演，B+树在MySQL的落地形式
文章目录
- 一、什么是索引
-
- 1、索引初体验
- 2、索引图解
- 3、索引类型
- 二、索引存储模型推演
-
- 1、二分查找
- 2、二叉查找树（BST Binary Search Tree）
- 3、平衡二叉树（AVL Tree）（左旋、右旋）
-
- （1）平衡二叉树的调整
- （2）平衡二叉树的索引
- （3）AVL树用于存储索引数据
- 4、多路平衡查找树（B Tree） （分裂、合并）
-
- （1）查找实例
- （2）B Tree保持平衡的秘诀
- 5、B+树（加强版多路平衡查找树）
-
- （1）B+Tree搜索过程
- （2）B+Tree带来的优势
- 6、为什么不用红黑树？
- 6、hash索引
-
- （1）哈希索引的特点
- （2）注意
- 三、B+Tree的落地实现
-
- 1、认识MySQL数据存储文件
- 2、MyISAM
-
- （1）MyISAM索引机制
- 3、InnoDB
-
- （1）聚集索引（聚簇索引）
- （2）二级索引
- （3）一个表没有主键
一、什么是索引
1、索引初体验
user_innodb这张表里有4个字段，id，name，gender，phone。
当这张表有500万条数据，在没有索引的name字段上执行一条where查询：
select * from user_innodb where name = '张三';
如果name字段上有索引呢？我们在name字段上面创建一个索引，再来执行一下查询：
-- name字段创建索引
ALTER TABLE user_innodb DROP INDEX idx_user_name;
ALTER TABLE user_innodb ADD INDEX idx_user_name (name);
我们再来执行一下select语句。
我们会发现，有索引的查询和没有索引的查询相比，效率竟相差几十倍。
索引到底是什么呢？为什么可以对我们的查询产生这么大的影响？创建索引的时候做了什么事情？
2、索引图解
维基百科上对数据库索引的定义：
数据库索引，是数据库管理系统（DBMS）中一个排序的数据结构，以协助快速查询、更新数据库表中数据。
数据是以文件的形式存放在磁盘上面的，每一行数据都有它的磁盘地址。如果没有索引的花，我们要从500万行数据里面检索一条数据，只能依次遍历这张表的全部数据，直到找到这条数据。
但是我们有了索引之后，只需要在索引里面去检索这条数据就行了，因为它是一种特殊的专门用来快速检索的数据结构，我们找到数据存放的磁盘地址以后，就可以拿到数据了。
索引就像是一本书的目录一样，目录可能只有几页的内容，根据拼音或者偏旁有序进行排序的，我们可以通过目录很快的定位到书中具体的内容。同样的，我们可以根据索引也可以很快的定位到这一条数据。
3、索引类型
从navicat中我们可以看到，索引包含索引名称、索引字段、索引类型总共有三种、索引方法有两种、注释。
在InnoDB中，索引类型有三种：
- Normal 普通索引：也叫非唯一索引，是最普通的索引，没有任何的限制。
- Full Text 全文索引：针对比较大的数据，比如我们存放的是消息内容、一篇文章，有几kb的数据的这种情况，如果要解决like查询在全文匹配的时候效率低的问题，可以创建全文索引。只有文本类型的字段才可以创建全文索引，比如char、varchar、text。
- Unique 唯一索引：唯一索引要求键值不能重复。另外需要注意的是，主键索引是一种特殊的唯一索引，它还多了一个限制条件，要求键值不能为空。主键索引用primay key创建。
注！SPATIAL 空间索引：空间索引是对空间数据类型的字段建立的索引，MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON。MYSQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MYISAM的表中创建。
二、索引存储模型推演
1、二分查找
算法-查找算法-线性表的查找（类C语言版）
二分查找的思想，也叫折半查找，每次都把候选数据缩小了一半。如果数据已经排过序的话，这种方式效率比较高。
所以首先，我们可以考虑使用有序数组作为索引的数据结构。有序数组的等值查询和比较查询效率非常高，但是更新数据的时候会出现一个问题，可能要挪动大量的数据（改变index），所以只适合存储静态的数据。
为了支持频繁的修改，比如插入数据，我们需要采用链表，但是链表的话，如果是单链表，它的查找效率还是不够高。
所以，有没有可以使用二分查找的链表呢？为了解决这个问题，BST（Binary Search Tree）也就是我们所说的二叉查找树就诞生了。
2、二叉查找树（BST Binary Search Tree）
算法-查找算法-树表的查找（二叉排序树、平衡二叉树）（类C语言版）
二叉查找树的 特点是什么？左子树所有的节点都小于父节点，右子树所有的节点都大于父节点。投影到平面以后，就是一个有序的线性表。
二叉查找树既能够实现快速查找，又能够实现快速插入。
但是二叉查找树有一个问题：就是它的查找耗时是和这棵树的深度相关的，在最坏的情况下时间复杂度会退化成O(n)。
什么情况是最坏的情况呢？
还是刚才这一批数字，如果我们插入的数据刚好是有序的，它会变成链表（我们把这种树叫做“斜树”），这种情况下不能达到加快检索速度的目的，和顺序查找效率是没有区别的。
造成它倾斜的原因是什么呢？
因为左右子树深度差太大，这棵树的左子树根本没有节点——也就是它不够平衡。
所以，我们有没有左右子树深度相差不是那么大，更加平衡的树呢？
这个就是平衡二叉树，叫做Balanced binary search trees，或者AVL树（AVL是发明这个数据结构的两位作者的名字简写：G.M.Adelson-Velsky和E.M.Landis）。
3、平衡二叉树（AVL Tree）（左旋、右旋）
算法-查找算法-树表的查找（二叉排序树、平衡二叉树）（类C语言版）
AVL Trees（Balanced binary search trees） 平衡二叉树的定义：左右子树深度差绝对值不能超过1。
比如左子树的深度是2，右子树的深度只能是1、2、3，这个时候我们再按顺序插入数据，不会变成一棵“斜树”。
那它的平衡是怎么做到的呢？怎么保证左右子树的深度差不能超过1呢？
（1）平衡二叉树的调整
举个例子，我们依次插入1、2、3，我们注意看，当我们插入了1、2之后，如果按照二叉查找树的定义，3肯定是要在2的右边的，这个时候根节点1的右节点深度会变成2，但是左节点的深度是0，因为它没有子节点，所以就会违反平衡二叉树的定义。
应该怎么办呢？因为它是右节点下面接一个右节点，属于“右-右”型，所以这个时候我们要把2提上去，这个操作叫做左旋。
同样的，如果我们插入7、6、5，这个时候就会变成左左型，就会发生右旋操作，把6提上去。
所以，为了保持平衡，AVL树在插入和更新数据的时候执行了一系列的计算和调整的操作。
平衡的问题我们解决了，那么平衡二叉树作为索引怎么查询数据？
（2）平衡二叉树的索引
在平衡二叉树中，一个节点，它的大小是一个固定的单位，作为索引应该存储建立索引的字段的值，叫做键值，比如id的值。还要存完整记录在磁盘上的地址。由于AVL树是二叉树，所以还要额外地存储左右子树的指针。
如图所示，
第一个是索引的键值。比如我们在id上面创建了一个索引，我在用where id = 1的条件查询的时候就会找到索引里面的id的这个键值。
第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。
第三个，因为是二叉树，它必须还要有左子结点和右子节点的引用，这样我们才能找到下一个结点。比如大于26的时候，走右边，到下一个树的节点，继续判断。
如果是这样存储数据的话，会有什么问题呢？
（3）AVL树用于存储索引数据
首先，索引的数据，是放在硬盘上的。查看数据和索引的大小：
select
concat(round(sum(data_length/1024/1024),2),'MB') AS data_len,
concat(round(sum(index_length/1024/1024),2),'MB') AS index_len
from information_schema.TABLES
where table_schema='ourea' and table_name='sys_member';
当我们用树的结构来存储索引的时候，访问一个节点就要跟磁盘之间发生一次IO操作。InnoDB操作磁盘的最小的单位是一页（或者叫一个磁盘块），大小事16KB（16384字节）。
那么，一个树的节点必须设计成16K大小，不然就会出现读不完或者读不够的情况。如果我们一个字节只存一个键值+数据+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远远达不到16K的容量。
想象一下，我们基于索引查找数据的时候，肯定是希望一次从磁盘加载很多的数据到内存中进行比较，这样就可以尽快拿到完整的数据，如果一个节点只存1个这样的单元，就需要读更多的节点，发生 更多的IO操作。
如果是机械硬盘时代，每次从磁盘读取数据需要10ms左右的寻址时间，交互次数越多，消耗的时间就越多。
比如上面的图，一张表里面有6条数据，当我们查询id=66的时候，要查询两个子节点，需要跟磁盘交互3次，如果我们有几百万数据呢？这个时间更加难以估计。
怎么解决？一就是让每个节点存储更多的数据。二就是节点上的关键字数量越多，我们的指针数也越多，也就意味着可以有更多的分叉（我们把它叫做“路数”）。
因为分叉越多，树的深度就会减少（根节点是0）。
这样，我们的数就从原来的高瘦的样子，变成了矮胖的样子。这时，我们的树就不再是二叉了，而是多叉，或者叫做多路。
4、多路平衡查找树（B Tree） （分裂、合并）
算法-B-树、B树、B+树详解
Balanced Tree就是我们说的多路平衡查找树，叫做B Tree（B代表平衡）。
跟AVL（平衡二叉树）一样，B树在枝节点和叶子结点存储键值、数据地址、节点引用。
它有一个特点：分叉数（路数）永远比关键字数多1。 比如我们画的这棵树，每个节点存储两个关键字，那么就会有三个指针指向三个子节点（当然肯定不只存3个这么少）。
（1）查找实例
B Tree的查找规则是什么样的呢？
比如我们要在这张表里面查找15，因为15小于17走左边；15大于12走右边。在磁盘块7里面就找到了15，只用了3次IO。
（2）B Tree保持平衡的秘诀
这确实比AVL（平衡二叉树）效率更高，那B Tree是怎么实现一个节点存储多个关键字，还能保持平衡的呢？跟AVL树有什么区别？
比如Max Degree（路数）是3的时候，我们插入数据1、2、3，在插入3的时候，本来应该在第一个磁盘块，但是如果一个节点有三个关键字的时候，意味着有4个指针，子节点会变成4路，所以这个时候必须进行分裂。把中间的数据2提上去，把1和3变成2的子节点。
如果删除节点，会有相反的合并的操作。
注意这里是分裂和合并，跟AVL树的左旋和右旋是不一样的。
我们继续插入4和5，B Tree又会出现分裂和合并的操作。
从这个里面我们也能看到，在更新索引的时候会有大量的索引的结构的调整，所以解释了为什么我们不要在频繁更新的列上建索引，或者为什么不要更新主键。
节点和分裂和合并，其实就是InnoDB页的分裂和合并。
如果索引键值有序，写满一页接着开辟一个新的页：
如果索引键值无序，存储过程造成大量磁盘碎片，带来频繁的page分裂和合并：
5、B+树（加强版多路平衡查找树）
算法-B-树、B树、B+树详解
B Tree的效率已经很高了，为什么MySQL还要对B Tree进行改良，最终使用了B+Tree呢？
总体上来说，这个B树的改良版本解决的问题比B Tree更全面。我们来看一下InnoDB里面的B+树的存储结构：
MySQL中的B+Tree有几个特点：
1、它的关键字的数量是跟路数相等的；
2、B+Tree的根节点和枝节点中都不会存储数据，只有叶子结点才存储数据。
搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索id = 28，虽然在第一层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点。
3、B+Tree的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。
（1）B+Tree搜索过程
1、比如我们要查找28，在根节点就找到了键值，但是因为它不是叶子结点，所以会继续往下搜寻，28是[28,66)的左闭右开的区间的临界值，所以会走中间的子节点，然后继续搜索，它又是[28,34)的左闭右开区间的临界值，所以会走左边的子节点，最后在叶子节点上找到了需要的数据。
2、第二个，如果是范围查询，比如要查询从22到60的数据，当找到22之后，只需要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高了区间查询效率（不需要返回上层父节点重复遍历查找）。
（2）B+Tree带来的优势
1、它是B Tree的变种，B Tree能解决的问题，它都能解决。B Tree解决的两大问题，就是每个节点存储更多的关键字、路数更多。
2、扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵B+Tree拿到所有的数据）。
3、B+Tree的磁盘读写能力相对于B Tree来说更强（根节点和枝节点不保存数据，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多）。
4、排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链表）。
5、效率更加稳定（B+Tree永远是在叶子结点拿数据，所以IO次数是最稳定的）。
举个例子：假设一条记是16bytes，一个叶子结点（一页）可以存储10条记录。非叶子结点可以存储多少个指针？
假设索引字段+指针大小为16字节。非叶子结点（一页）可以存储1000个这样的单元（键值+指针），代表有1000个指针。
树深度为2的时候，有10002个叶子节点，可以存储的数据位1000W（千万级别）。
在查找数据时，一次页的查找代表一次IO，也就是说，一张千万级别的表，查询数据最多需要访问3次磁盘。
树的深度是怎么来的？根据你的键值类型和数据量计算出来的。字段值越大、数据量越大，深度越大。
所以在InnoDB中B+树深度一般为1-3层，它就能满足千万级的数据存储。
因为B Tree和B+Tree的特性，它们广泛地用在文件系统和数据库中，例如windows的HPFS文件系统，Oracle、MySQL、SQLServer数据库。
6、为什么不用红黑树？
红黑树也是BST树，但是不是严格平衡的，通过变色和旋转来保持平衡。
必须满足5个约束：
1、节点分为红色或者黑色；2、根节点必须是黑色的；3、叶子节点都是黑色的NULL节点；4、红色节点的两个子节点都是黑色（不允许两个相邻的红色节点）；5、从任意节点触发，到其每个叶子节点的路径中包含相同数量的黑色节点。
插入60、56、68、45、64、58、72、43、49
基于以上规则，可以推导出：从根节点到叶子节点的最长路径（红黑相间的路径）不大于最短路径（全部是黑色节点）的2倍。
为什么不用红黑树？1、只有两路；2、不够平衡。
红黑树一般只放在内存里面用。例如Java的TreeMap，它可以用来实现一致性哈希。
6、hash索引
算法-hash散列表查找详解
在navicat工具中，创建索引，索引方式还有一种是HASH索引，以KV的形式检索数据，也就是说，它会根据索引字段生成哈希码和指针，指针指向数据。
（1）哈希索引的特点
1、它的事件复杂度是O(1)，查询速度比较快。因为哈希索引里面的数据不是按顺序存储的，所以不能用于排序。
2、我们在查询数据的时候要根据键值计算哈希码，所以它只能支持等值查询（= IN），不支持范围查询（> < >= <= between and）。
3、如果字段重复值很多的时候，会出现大量的哈希冲突（采用拉链法解决），效率会降低。
（2）注意
在InnoDB中，不能显式地创建一个哈希索引（所谓的支持哈希索引指的是AHI，自适应哈希，它是InnoDB自动为buffer pool中的热点页创建的索引）。
memory存储引擎可以使用Hash索引。
三、B+Tree的落地实现
1、认识MySQL数据存储文件
首先，MySQL的数据都是文件的形式存放在磁盘中的，我们可以找到这个数据目录的地址。在MySQL中有这么一个参数，我们来看一下：
show variables like 'datadir';
每个数据库有一个目录，我们新建了一个叫做test的数据库，那么这里就有一个test的文件夹。
数据库里面的几张表，进入test目录之后，发现这里面有一些跟我们创建的表名对应的文件。
在这里我们能看到，每张InnoDB的表有两个文件（.frm和.ibd），MyISAM的表有三个文件（.frm、.MYD、.MYI）。
有一个是相同的文件.frm。.frm是MySQL里面表结构定义的文件，不管你建表的时候选用任何一个存储引擎都会生成。
主要是其他两个文件，实现了MySQL不同存储引擎的索引。
2、MyISAM
在MyISAM里面，有另外两个文件：
一个是.MYD文件，D代表Data，是MyISAM的数据文件，存放数据记录，比如我们的user_myisam表的所有的表数据。
一个是.MYI文件，I代表Index，是MyISAM的索引文件，存放索引，比如我们在id字段上面创建了一个主键索引，那么主键索引就是在这个索引文件里面。一个索引就会有一棵B+Tree，所有的B+Tree都在这个myi文件里面。
也就是说，在MyISAM里面，索引和数据是两个独立的文件。
（1）MyISAM索引机制
MyISAM的B+Tree里面，叶子节点存储的事数据文件对应的磁盘地址。所以从索引文件.MYI中找到键值后，会到数据文件.MYD中获取相应的数据记录。
除了主键索引，在MyISAM中，其他索引也在这个.MYI文件里面。
-- name字段创建索引
ALTER TABLE user_innodb DROP INDEX idx_user_name;
ALTER TABLE user_innodb ADD INDEX idx_user_name (name);
非主键索引跟主键索引存储和检索数据的方式是没有任何区别的，一样是在索引文件里面找到磁盘地址，然后到数据文件里面获取数据。
3、InnoDB
与MyISAM不同，在InnoDB的某个索引的叶子节点上，它直接存储了我们的数据。
所以，为什么说在InnoDB中索引即数据，数据即索引，就是这个原因。
但是会有一个问题，一张InnoDB的表可能有很多个索引，数据肯定是只有一份的，那数据在哪个索引的叶子节点上呢？
（1）聚集索引（聚簇索引）
InnoDB引入了聚集索引（聚簇索引）的概念。索引键值的逻辑顺序跟表数据行的物理存储顺序是一致的。
InnoDB组织数据的方式就是（聚集）索引组织表（clustered index organize table）。如果说一张表创建了主键索引，那么这个主键索引就是聚集索引，决定数据行的物理存储顺序。
（比如字典的目录是按拼音排序的，内容也是按拼音排序的，按拼音排序的这种目录就叫聚集索引）
那么问题来了，主键索引之外的索引，会不会也把完整记录在叶子节点放一份呢？答案是并不会，因为这会带来额外的存储空间浪费和计算消耗。
它们的叶子结点上没有数据怎么检索完整数据？比如我们在name字段上面建的普通索引。
（2）二级索引
InnoDB中，主键索引和辅助索引是有一个主次之分的。如果有主键索引，那么主键索引就是聚集索引。其他的索引统一叫做“二级索引”（secondary index）。
二级索引存储的是二级索引的键值，例如在name上建立索引，节点上存的是name的值，qingshan tom等等（很明显，它的键值逻辑顺序跟物理行的顺序不一致）。
而二级索引的叶子节点存的是这条记录对应的主键的值。比如qingshan id = 1，jack id = 4等等。
所以，二级索引检索数据的流程是这样的：
当我们用name索引查询一条记录，它会在二级索引的叶子节点找到name=zhangsan，拿到主键，也就是id=1，然后再到主键索引的叶子节点拿到数据。
为什么不存地址而存键值呢？因为地址会发生变化。
从这个角度来说，因为主键索引比二级索引少扫描了一棵B+Tree（避免了回表），它的速度相对会快一些。
（3）一个表没有主键
一张表没有主键怎么办？完整的记录放在哪个索引的叶子节点？数据放在那里？
1、如果我们定义了主键（PRIMARY KEY），那么InnoDB会选择主键作为聚集索引。
2、如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。
3、如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐藏的聚集索引，它会随着记录的写入而主键递增。
select _rowid name from t;