MySQL在我们工作中都会用到，那么我们最常接触的阶索计就是增删改查，而对于增删改查来说，我们更多的是查询。但是引设面试中，面试官又不会问你什么查询是怎么写的，都是问一些索引啊，事务啊， 底层结构这些东西，所以我打算分四篇去逐一的过一遍MySQL的知识点。 以下为四篇的推演传送门，有需要直接点击进入，目前还在建设当中，可以关注作者或专栏，持续更新，永不收费 。 
| DDL查询篇 | 传送门 |
| MySQL函数 、视图 、引设存储过程及触发器 | 传送门 |
| MySQL约束 | 传送门 |
| MySQL高阶——索引设计的推演推演 | – |
| MySQL事务及架构 | – |
索引是引设存储引擎用于快速找到数据记录的一种数据结构，就好比一本教科书的目录部分，通过目录中找到对应文章的页码，便可快速定位到需要的文章 。MySQL中也是推演一样的道理，进行数据查找时，首先查看查询条件是否命中某条索引，符合则通过索引查找相关数据，如果不符合则需要全表扫描，即需要一条一条地查找记录，直到找到与条件符合的记录 。 
如上图所示，数据库没有索引的情况下，数据分布在硬盘不同的位置上面，读取数据时，摆臂需要前后摆动查询数据，这样操作非常消耗时间 。如果数据顺序摆放，那么也需要从1到6行按顺序读取，这样就相当于进行了6次IO操作，依旧非常耗时 。如果我们不借助任何索引结构帮助我们快速定位数据的话，我们查找 Col 2 = 89 这条记录，就要逐行去查找 、去比较 。从Col 2 = 34 开始，进行比较，发现不是，继续下一行 。我们当前的表只有不到10行数据，但如果表很大的话，有上千万条数据，就意味着要做很多很多次硬盘I/0才能找到 。现在要查找 Col 2 = 89 这条记录 。CPU必须先去磁盘查找这条记录，找到之后加载到内存，再对数据进行处理 。这个过程最耗时间就是磁盘I/O（涉及到磁盘的旋转时间（速度较快），磁头的寻道时间(速度慢、费时)）
假如给数据使用 二叉树 这样的数据结构进行存储，如下图所示 
对字段 Col 2 添加了索引，就相当于在硬盘上为 Col 2 维护了一个索引的数据结构，即这个 二叉搜索树。二叉搜索树的每个结点存储的是 (K, V) 结构，key 是 Col 2，value 是该 key 所在行的文件指针（地址）。比如：该二叉搜索树的根节点就是：(34, 0x07) 。现在对 Col 2 添加了索引，这时再去查找 Col 2 = 89 这条记录的时候会先去查找该二叉搜索树（二叉树的遍历查找） 。读 34 到内存，89 > 34; 继续右侧数据，读 89 到内存，89==89；找到数据返回 。找到之后就根据当前结点的 value 快速定位到要查找的记录对应的地址 。我们可以发现，只需要 查找两次 就可以定位到记录的地址，查询速度就提高了 。
这就是我们为什么要建索引，目的就是为了 减少磁盘I/O的次数，加快查询速率 。
MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构 。
索引的本质：索引是数据结构 。你可以简单理解为“排好序的快速查找数据结构”，满足特定查找算法 。 这些数据结构以某种方式指向数据， 这样就可以在这些数据结构的基础上实现 高级查找算法 。
索引是在存储引擎中实现的，因此每种存储引擎的索引不一定完全相同，并且每种存储引擎不一定支持所有索引类型 。同时，存储引擎可以定义每个表的 最大索引数和 最大索引长度 。所有存储引擎支持每个表至少16个索引，总索引长度至少为256字节 。有些存储引擎支持更多的索引数和更大的索引长度 。
（1）类似大学图书馆建书目索引，提高数据检索的效率，降低 数据库的IO成本 ，这也是创建索引最主 要的原因 。
（2）通过创建唯一索引，可以保证数据库表中每一行 数据的唯一性 。
（3）在实现数据的参考完整性方面，可以 加速表和表之间的连接 。换句话说，对于有依赖关系的子表和父表联合查询时， 可以提高查询速度 。
（4）在使用分组(GROUP BY)和排序(ORDER BY)子句进行数据查询时，可以显著 减少查询中分组和排序的时间 ，降低了CPU的消耗 。
增加索引也有许多不利的方面，主要表现在如下几个方面：
（1）创建索引和维护索引要 耗费时间 ，并 且随着数据量的增加，所耗费的时间也会增加 。
（2）索引需要占 磁盘空间 ，除了数据表占数据空间之 外，每一个索引还要占一定的物理空间， 存储在磁盘上 ，如果有大量的索引，索引文件就可能比数据文 件更快达到最大文件尺寸。
（3）虽然索引大大提高了查询速度，同时却会 降低更新表的速度 。当对表 中的数据进行增加 、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度 。 因此，选择使用索引时，需要综合考虑索引的优点和缺点 。
提示：
索引可以提高查询的速度，但是会影响插入记录的速度 。这种情况下，最好的办法是先删除表中的索引，然后插入数据，插入完成后再创建索引。
先来看一个精确匹配的例子：
SELECT [列名列表] FROM 表名 WHERE 列名 = xxx;假设目前表中的记录比较少，所有的记录都可以被存放到一个页中，在查找记录的时候可以根据搜索条件的不同分为两种情况：
以主键为搜索条件
可以在页目录中使用 二分法 快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定记录 。
以其他列作为搜索条件
因为在数据页中并没有对非主键列建立所谓的页目录，所以我们无法通过二分法快速定位相应的槽。这种情况下只能从 最小记录 开始 依次遍历单链表中的每条记录， 然后对比每条记录是不是符合搜索条件 。很显然，这种查找的效率是非常低的。
在很多页中查找记录的活动可以分为两个步骤：
在没有索引的情况下，不论是根据主键列或者其他列的值进行查找，由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表 一直往下找，在每一个页中根据我们上面的查找方式去查 找指定的记录 。因为要遍历所有的数据页，所以这种方式显然是 超级耗时 的 。如果一个表有一亿条记录呢？此时 索引 应运而生 。
建一个表：
mysql> CREATE TABLE index_demo(-> c1 INT,-> c2 INT,-> c3 CHAR(1),-> PRIMARY KEY(c1)-> ) ROW_FORMAT = Compact;这个新建的 index_demo 表中有2个INT类型的列，1个CHAR(1)类型的列，而且我们规定了c1列为主键， 这个表使用 Compact 行格式来实际存储记录的 。这里我们简化了index_demo表的行格式示意图： 
我们只在示意图里展示记录的这几个部分：
将记录格式示意图的其他信息项暂时去掉并把它竖起来的效果就是这样： 
把一些记录放到页里的示意图就是： 
我们在根据某个搜索条件查找一些记录时为什么要遍历所有的数据页呢？因为各个页中的记录并没有规律，我们并不知道我们的搜索条件匹配哪些页中的记录，所以不得不依次遍历所有的数据页。所以如果我们 想快速的定位到需要查找的记录在哪些数据页 中该咋办？我们可以为快速定位记录所在的数据页而建立一个目录 ，建这个目录必须完成下边这些事：
下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值 。
假设：每个数据结构最多能存放3条记录（实际上一个数据页非常大，可以存放下好多记录） 。
INSERT INTO index_demo VALUES(1, 4, 'u'), (3, 9, 'd'), (5, 3, 'y'); 那么这些记录以及按照主键值的大小串联成一个单向链表了，如图所示： 
从图中可以看出来， index_demo 表中的3条记录都被插入到了编号为10的数据页中了 。此时我们再来插入一条记录
因为 页10 最多只能放3条记录，所以我们不得不再分配一个新页： 
注意：新分配的 数据页编号可能并不是连续的 。它们只是通过维护上一个页和下一个页的编号而建立了 链表 关系
。另外，页10中用户记录最大的主键值是5，而页28中有一条记录的主键值是4，因为5>4，所以这就不符合下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值的要求，所以在插入主键值为4的记录的时候需要伴随着一次 记录移动，也就是把主键值为5的记录移动到页28中，然后再把主键值为4的记录插入到页10中，这个过程的示意图如下： 
这个过程表明了在对页中的记录进行增删改查操作的过程中，我们必须通过一些诸如 记录移动 的操作来始终保证这个状态一直成立：下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值 。这个过程称为 页分裂
。
由于数据页的 编号可能是不连续 的，所以在向 index_demo 表中插入许多条记录后，可能是这样的效果： 
我们需要给它们做个 目录，每个页对应一个目录项，每个目录项包括下边两个部分：
1）页的用户记录中最小的主键值，我们用 key 来表示 。
2）页号，我们用 page_on 表示。 
以 页28 为例，它对应 目录项2 ，这个目录项中包含着该页的页号 28 以及该页中用户记录的最小主 键值 5 。我们只需要把几个目录项在物理存储器上连续存储（比如：数组），就可以实现根据主键 值快速查找某条记录的功能了
。比如：查找主键值为 20 的记录，具体查找过程分两步：
至此，针对数据页做的简易目录就搞定了 。这个目录有一个别名，称为 索引 。
InnoDB怎么区分一条记录是普通的 用户记录 还是 目录项记录 呢？使用记录头信息里的 record_type 属性，它的各自取值代表的意思如下：
我们把前边使用到的目录项放到数据页中的样子就是这样： 
从图中可以看出来，我们新分配了一个编号为30的页来专门存储目录项记录 。这里再次强调 目录项记录 和普通的 用户记录 的不同点：
相同点：两者用的是一样的数据页，都会为主键值生成 Page Directory （页目录），从而在按照主键值进行查找时可以使用 二分法 来加快查询速度。
现在以查找主键为 20 的记录为例，根据某个主键值去查找记录的步骤就可以大致拆分成下边两步：
从图中可以看出，我们插入了一条主键值为320的用户记录之后需要两个新的数据页：
现在因为存储目录项记录的页不止一个，所以如果我们想根据主键值查找一条用户记录大致需要3个步骤，以查找主键值为 20 的记录为例：
如果我们表中的数据非常多则会产生很多存储目录项记录的页，那我们怎么根据主键值快速定位一个存储目录项记录的页呢？那就为这些存储目录项记录的页再生成一个更高级的目录，就像是一个多级目录一样，大目录里嵌套小目录，小目录里才是实际的数据，所以现在各个页的示意图就是这样子： 
如图，我们生成了一个存储更高级目录项的 页33 ，这个页中的两条记录分别代表页30和页32，如果用 户记录的主键值在 [1, 320) 之间，则到页30中查找更详细的目录项记录，如果主键值 不小于320 的 话，就到页32中查找更详细的目录项记录。
我们可以用下边这个图来描述它： 
这个数据结构，它的名称是 B+树
。
一个B+树的节点其实可以分成好多层，规定最下边的那层，也就是存放我们用户记录的那层为第 0 层， 之后依次往上加 。之前我们做了一个非常极端的假设：存放用户记录的页 最多存放3条记录 ，存放目录项 记录的页 最多存放4条记录 。其实真实环境中一个页存放的记录数量是非常大的，假设所有存放用户记录的叶子节点代表的数据页可以存放 100条用户记录 ，所有存放目录项记录的内节点代表的数据页可以存 放 1000条目录项记录 ，那么：
你的表里能存放 100000000000 条记录吗？所以一般情况下，我们用到的 B+树都不会超过4层 ，那我们通过主键值去查找某条记录最多只需要做4个页面内的查找（查找3个目录项页和一个用户记录页），又因为在每个页面内有所谓的 Page Directory （页目录），所以在页面内也可以通过 二分法 实现快速 定位记录 。
索引按照物理实现方式，索引可以分为 2 种：聚簇（聚集）和非聚簇（非聚集）索引。我们也把非聚集 索引称为二级索引或者辅助索引 。
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式（所有的用户记录都存储在了叶子结点），也就是所谓的 索引即数据，数据即索引 。
术语"聚簇"表示当前数据行和相邻的键值聚簇的存储在一起
特点：
使用记录主键值的大小进行记录和页的排序，这包括三个方面的含义：
B+树的 叶子节点 存储的是完整的用户记录。
所谓完整的用户记录，就是指这个记录中存储了所有列的值（包括隐藏列）。
我们把具有这两种特性的B+树称为聚簇索引，所有完整的用户记录都存放在这个聚簇索引的叶子节点处。这种聚簇索引并不需要我们在MySQL语句中显式的使用INDEX 语句去创建， InnDB 存储引擎会 自动 的为我们创建聚簇索引 。
优点：
缺点：
如果我们想以别的列作为搜索条件该怎么办？肯定不能是从头到尾沿着链表依次遍历记录一遍 。
答案：我们可以多建几颗B+树，不同的B+树中的数据采用不同的排列规则 。比方说我们用c2列的大小作为数据页、页中记录的排序规则，再建一棵B+树，效果如下图所示： 
这个B+树与上边介绍的聚簇索引有几处不同： 
**概念：回表
我们根据这个以c2列大小排序的B+树只能确定我们要查找记录的主键值，所以如果我们想根 据c2列的值查找到完整的用户记录的话，仍然需要到 聚簇索引 中再查一遍，这个过程称为 回表 。也就 是根据c2列的值查询一条完整的用户记录需要使用到 2 棵B+树！
问题：为什么我们还需要一次 回表 操作呢？直接把完整的用户记录放到叶子节点不OK吗？
回答：
如果把完整的用户记录放到叶子结点是可以不用回表。但是太占地方了，相当于每建立一课B+树都需要把所有的用户记录再都拷贝一遍，这就有点太浪费存储空间了 。
因为这种按照非主键列建立的B+树需要一次回表操作才可以定位到完整的用户记录，所以这种B+树也被称为二级索引，或者辅助索引 。由于使用的是c2列的大小作为B+树的排序规则，所以我们也称这个B+树为c2列建立的索引 。
非聚簇索引的存在不影响数据在聚簇索引中的组织，所以一张表可以有多个非聚簇索引 。 
小结：聚簇索引与非聚簇索引的原理不同，在使用上也有一些区别：
我们也可以同时以多个列的大小作为排序规则，也就是同时为多个列建立索引，比方说我们想让B+树按 照 c2和c3列 的大小进行排序，这个包含两层含义：
为c2和c3建立的索引的示意图如下： 
如图所示，我们需要注意以下几点：
注意一点，以c2和c3列的大小为排序规则建立的B+树称为 联合索引 ，本质上也是一个二级索引 。它的意 思与分别为c2和c3列分别建立索引的表述是不同的，不同点如下：
实际上B+树的形成过程是这样的：
这个过程特别注意的是：一个B+树索引的根节点自诞生之日起，便不会再移动 。这样只要我们对某个表建议一个索引，那么它的根节点的页号便会被记录到某个地方 。然后凡是 InnoDB 存储引擎需要用到这个索引的时候，都会从哪个固定的地方取出根节点的页号，从而来访问这个索引 。
我们知道B+树索引的内节点中目录项记录的内容是 索引列 + 页号 的搭配，但是这个搭配对于二级索引来说有点不严谨 。还拿 index_demo 表为例，假设这个表中的数据是这样的： 
如果二级索引中目录项记录的内容只是 索引列 + 页号 的搭配的话，那么为 c2 列简历索引后的B+树应该长这样： 
如果我们想新插入一行记录，其中 c1
、c2
、c3 的值分别是: 9
、1 、c, 那么在修改这个为 c2 列建立的二级索引对应的 B+ 树时便碰到了个大问题：由于 页3 中存储的目录项记录是由 c2列 + 页号 的值构成的，页3 中的两条目录项记录对应的 c2 列的值都是1，而我们 新插入的这条记录 的 c2 列的值也是 1，那我们这条新插入的记录到底应该放在 页4 中，还是应该放在 页5 中？答案：对不起，懵了
为了让新插入记录找到自己在那个页面，我们需要保证在B+树的同一层页节点的目录项记录除页号这个字段以外是唯一的 。所以对于二级索引的内节点的目录项记录的内容实际上是由三个部分构成的：
也就是我们把主键值也添加到二级索引内节点中的目录项记录，这样就能保住 B+ 树每一层节点中各条目录项记录除页号这个字段外是唯一的，所以我们为c2建立二级索引后的示意图实际上应该是这样子的： 
这样我们再插入记录(9, 1, 'c') 时，由于 页3 中存储的目录项记录是由 c2列 + 主键 + 页号 的值构成的，可以先把新纪录的 c2 列的值和 页3 中各目录项记录的 c2 列的值作比较，如果 c2 列的值相同的话，可以接着比较主键值，因为B+树同一层中不同目录项记录的 c2列 + 主键的值肯定是不一样的，所以最后肯定能定位唯一的一条目录项记录，在本例中最后确定新纪录应该被插入到 页5 中 。
一个B+树只需要很少的层级就可以轻松存储数亿条记录，查询速度相当不错！这是因为B+树本质上就是一个大的多层级目录，每经过一个目录时都会过滤掉许多无效的子目录，直到最后访问到存储真实数据的目录。那如果一个大的目录中只存放一个子目录是个啥效果呢？那就是目录层级非常非常多，而且最后的那个存放真实数据的目录中只存放一条数据 。所以 InnoDB 的一个数据页至少可以存放两条记录 。
B树索引使用存储引擎如表所示：
| B-Tree索引 | 支持 | 支持 | 支持 |
即使多个存储引擎支持同一种类型的索引，但是他们的实现原理也是不同的 。Innodb和MyISAM默认的索引是Btree索引；而Memory默认的索引是Hash索引 。
MyISAM引擎使用 B+Tree 作为索引结构，叶子节点的data域存放的是 数据记录的地址 。
MyISAM的索引方式都是“非聚簇”的，与InnoDB包含1个聚簇索引是不同的 。小结两种引擎中索引的区别：
① 在InnoDB存储引擎中，我们只需要根据主键值对 聚簇索引 进行一次查找就能找到对应的记录，而在 MyISAM 中却需要进行一次 回表 操作，意味着MyISAM中建立的索引相当于全部都是 二级索引 。
② InnoDB的数据文件本身就是索引文件，而MyISAM索引文件和数据文件是 分离的 ，索引文件仅保存数 据记录的地址。
③ InnoDB的非聚簇索引data域存储相应记录 主键的值 ，而MyISAM索引记录的是 地址 。换句话说， InnoDB的所有非聚簇索引都引用主键作为data域 。
④ MyISAM的回表操作是十分 快速 的，因为是拿着地址偏移量直接到文件中取数据的，反观InnoDB是通 过获取主键之后再去聚簇索引里找记录，虽然说也不慢，但还是比不上直接用地址去访问 。
⑤ InnoDB要求表 必须有主键 （ MyISAM可以没有 ）。如果没有显式指定，则MySQL系统会自动选择一个 可以非空且唯一标识数据记录的列作为主键 。如果不存在这种列，则MySQL自动为InnoDB表生成一个隐 含字段作为主键，这个字段长度为6个字节，类型为长整型 。
小结： 
索引是个好东西，可不能乱建，它在空间和时间上都会有消耗：
空间上的代价
每建立一个索引都要为它建立一棵B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会 占用 16KB 的存储空间，一棵很大的B+树由许多数据页组成，那就是很大的一片存储空间 。
时间上的代价
每次对表中的数据进行 增 、删 、改 操作时，都需要去修改各个B+树索引 。而且我们讲过，B+树每 层节点都是按照索引列的值 从小到大的顺序排序 而组成了 双向链表 。不论是叶子节点中的记录，还 是内节点中的记录（也就是不论是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序 而形成了一个单向链表 。而增、删 、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需 要额外的时间进行一些 记录移位 ， 页面分裂 、 页面回收 等操作来维护好节点和记录的排序 。如果 我们建了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿 。
一个表上索引建的越多，就会占用越多的存储空间，在增删改记录的时候性能就越差 。为了能建立又好又少的索引，我们得学学这些索引在哪些条件下起作用的 。
加快查找速度的数据结构，常见的有两类：
(1) 树，例如平衡二叉搜索树，查询/插入/修改/删除的平均时间复杂度都是 O(log2N);
(2)哈希，例如HashMap，查询/插入/修改/删除的平均时间复杂度都是 O(1); (key, value)
上图中哈希函数h有可能将两个不同的关键字映射到相同的位置，这叫做 碰撞 ，在数据库中一般采用 链接法来解决。在链接法中，将散列到同一槽位的元素放在一个链表中，如下图所示： 
实验：体会数组和hash表的查找方面的效率区别
// 算法复杂度为 O(n)@Testpublic void test1(){int[] arr = new int[100000];for(int i = 0;i < arr.length;i++){arr[i] = i + 1;}long start = System.currentTimeMillis();for(int j = 1; j<=100000;j++){int temp = j;for(int i = 0;i < arr.length;i++){if(temp == arr[i]){break;}}}long end = System.currentTimeMillis();System.out.println("time： " + (end - start)); //time： 823} // 算法复杂度为 O(1)@Testpublic void test2(){HashSetHash结构效率高，那为什么索引结构要设计成树型呢？
Hash索引适用存储引擎如表所示：
| HASH索引 | 不支持 | 不支持 | 支持 |
Hash索引的适用性： 
采用自适应 Hash 索引目的是方便根据 SQL 的查询条件加速定位到叶子节点，特别是当 B+ 树比较深的时候，通过自适应 Hash 索引可以明显提高数据的检索效率 。
我们可以通过 innodb_adaptive_hash_index 变量来查看是否开启了自适应 Hash，比如：
mysql> show variables like '%adaptive_hash_index';如果我们利用二叉树作为索引结构，那么磁盘的IO次数和索引树的高度是相关的 。
1. 二叉搜索树的特点
2. 查找规则
但是特殊情况，就是有时候二叉树的深度非常大，比如： 
为了提高查询效率，就需要 减少磁盘IO数 。为了减少磁盘IO的次数，就需要尽量 降低树的高度 ，需要把 原来“瘦高”的树结构变的“矮胖”，树的每层的分叉越多越好 。
`每访问一次节点就需要进行一次磁盘 I/O 操作，对于上面的树来说，我们需要进行 5次 I/O 操作 。虽然平衡二叉树的效率高，但是树的深度也同样高，这就意味着磁盘 I/O 操作次数多，会影响整体数据查询的效率 。
针对同样的数据，如果我们把二叉树改成 M 叉树 （M>2）呢？当 M=3 时，同样的 31 个节点可以由下面 的三叉树来进行存储： 
你能看到此时树的高度降低了，当数据量 N 大的时候，以及树的分叉树 M 大的时候，M叉树的高度会远小于二叉树的高度 (M > 2) 。所以，我们需要把 `树从“瘦高” 变 “矮胖”。
B 树的英文是 Balance Tree，也就是 多路平衡查找树。简写为 B-Tree 。它的高度远小于平衡二叉树的高度 。
B 树的结构如下图所示： 
一个 M 阶的 B 树（M>2）有以下的特性：
上面那张图所表示的 B 树就是一棵 3 阶的 B 树 。我们可以看下磁盘块 2，里面的关键字为（8，12），它 有 3 个孩子 (3，5)，(9，10) 和 (13，15)，你能看到 (3，5) 小于 8，(9，10) 在 8 和 12 之间，而 (13，15) 大于 12，刚好符合刚才我们给出的特征 。
然后我们来看下如何用 B 树进行查找。假设我们想要 查找的关键字是 9 ，那么步骤可以分为以下几步：
你能看出来在 B 树的搜索过程中，我们比较的次数并不少，但如果把数据读取出来然后在内存中进行比 较，这个时间就是可以忽略不计的。而读取磁盘块本身需要进行 I/O 操作，消耗的时间比在内存中进行 比较所需要的时间要多，是数据查找用时的重要因素。 B 树相比于平衡二叉树来说磁盘 I/O 操作要少 ， 在数据查询中比平衡二叉树效率要高
。所以 只要树的高度足够低，IO次数足够少，就可以提高查询性能 。 
再举例1：
B+ 树和 B 树的差异在于以下几点：
B 树和 B+ 树都可以作为索引的数据结构，在 MySQL 中采用的是 B+ 树 。 但B树和B+树各有自己的应用场景，不能说B+树完全比B树好，反之亦然 。
思考题：为了减少IO，索引树会一次性加载吗？
思考题：B+树的存储能力如何？为何说一般查找行记录，最多只需1~3次磁盘IO
思考题：为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？
思考题：Hash 索引与 B+ 树索引的区别
思考题：Hash 索引与 B+ 树索引是在建索引的时候手动指定的吗？ 
R-Tree在MySQL很少使用，仅支持 geometry数据类型 ，支持该类型的存储引擎只有myisam 、bdb 、 innodb 、ndb、archive几种 。举个R树在现实领域中能够解决的例子：查找20英里以内所有的餐厅。如果 没有R树你会怎么解决？一般情况下我们会把餐厅的坐标(x,y)分为两个字段存放在数据库中，一个字段记 录经度，另一个字段记录纬度 。这样的话我们就需要遍历所有的餐厅获取其位置信息，然后计算是否满 足要求 。如果一个地区有100家餐厅的话，我们就要进行100次位置计算操作了，如果应用到谷歌 、百度 地图这种超大数据库中，这种方法便必定不可行了 。R树就很好的 解决了这种高维空间搜索问题 。它把B 树的思想很好的扩展到了多维空间，采用了B树分割空间的思想，并在添加 、删除操作时采用合并 、分解 结点的方法，保证树的平衡性 。因此，R树就是一棵用来 存储高维数据的平衡树 。相对于B-Tree，R-Tree 的优势在于范围查找 。
| R-Tree索引 | 支持 | 支持 | 不支持 |
同一问题可用不同算法解决，而一个算法的质量优劣将影响到算法乃至程序的效率 。算法分析的目的在 于选择合适算法和改进算法 。 
✨ 原创不易，还希望各位大佬支持一下 \textcolor{blue}{原创不易，还希望各位大佬支持一下} 原创不易，还希望各位大佬支持一下 👍 点赞，你的认可是我创作的动力！ \textcolor{green}{点赞，你的认可是我创作的动力！} 点赞，你的认可是我创作的动力！ ⭐️ 收藏，你的青睐是我努力的方向！ \textcolor{green}{收藏，你的青睐是我努力的方向！} 收藏，你的青睐是我努力的方向！ ✏️ 评论，你的意见是我进步的财富！ \textcolor{green}{评论，你的意见是我进步的财富！} 评论，你的意见是我进步的财富！
