这一篇写的东西会很多，很多，因为我要把关于索引的所有东西都写在一起，由于本人对索引的概念很是模糊，只能现在先写出来，后期在慢慢理解。
在MySQL5.7之后存储引擎默认成了innodb，所以就主要讲解innodb的索引结构。
innodb存储引擎对于数据表结构
Innodb存储引擎用于管理数据的最小磁盘单位。常见的页类型有数据页，Undo页，系统页，事物数据页。下面主要分析的数据页。默认的页面大小为16kb，每个页中至少存储2条或以上的行记录
表空间
表空间分为了两种，这里简单的概括一下：
独立表空间：每一个表都将会生成以独立的文件方式来进行存储，每一个表都有一个.frm表描述文件，还有一个.ibd文件。 其中这个文件包括了单独一个表的数据内容以及索引内容，默认情况下它的存储位置也是在表的位置之中。
共享表空间： Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。
InnoDB把数据保存在表空间内，表空间可以看作是InnoDB存储引擎逻辑结构的最高层。本质上是一个由一个或多个磁盘文件组成的虚拟文件系统。InnoDB用表空间并不只是存储表和索引，还保存了回滚段、双写缓冲区等。
分片段(Segment)
段是表空间文件中的主要组织结构，它是一个逻辑概念，用来管理物理文件，是构成索引、表、回滚段的基本元素。
创建一个索引（B+树）时会同时创建两个段，分别是内节点段和叶子段，内节点段用来管理（存储）B+树非叶子（页面）的数据，叶子段用来管理（存储）B+树叶子节点的数据；也就是说，在索引数据量一直增长的过程中，所有新的存储空间的申请，都是从“段”这个概念中申请的。
页
页是InnoDB磁盘管理的最小单位 对于innodb来说就是 16KB 不过如果是oracle 或者SQLserver就是4kb的大小。
这里单单指的是数据页，数据页里边存储的是每一行数据，有用过数据库客户端的可以理解为就是一条一条数据
Innodb的数据结构跟索引有什么关系
为什么要写这里，这里需要你知道索引在表页中起的作用
之前写过：https://blog.csdn.net/fangkang7/article/details/98973186
认识索引
在MySQL中，主要有四种类型：分别为BTree索引，哈希索引，Fulltext索引，R-Tree索引
先介绍俩个概念，非叶节点，叶子节点
b+tree跟b-tree的区别
B+Tree相对于B-Tree有几点不同：
非叶子节点只存储键值信息。
所有叶子节点之间都有一个链指针。
数据记录都存放在叶子节点中。
每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。
B+树
索引的底层原理就是B+Tree
只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针。
主索引与辅助索引
主键索引（主索引）：在叶子节点存放的是数据
二级索引（辅助索引）：在叶子节点处存放的是这个表的主键
普通的索引找在叶子节点主键，主键索引在叶子节点找数据
在 InnoDB 存储引擎中，每一个索引都对应一棵 B+ Tree，InnoDB 的索引主要分为主索引和辅助索引：
主索引：包含记录的文件按照某个 key 制定的顺序排序，这个 key 就是主索引，也就是主键，也被称为聚簇索引。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚集索引。在 InnoDB 中，主索引的叶子节点存的是整行数据，这也意味着 InnoDB 中的表一定要有一个主索引；
辅助索引：某个 key 指定的顺序与文件记录的物理顺序不同，这个 key 就是辅助索引。InnoDB 中的辅助索引在叶子节点中并不存储实际的数据，只会包含主索引的值。这就意味着如果使用辅助索引进行数据的查找，只能查到主索引，然后根据这个主索引再次扫描以下主索引的树，进行一次回表操作；
索引在优化器中的执行流程
文章地址：https://blog.csdn.net/fangkang7/article/details/99443549
**索引B+Tree
B+tree是在二叉树的基础上演变来的。b+tree的定义实际上是比较的复杂的，b+tree视为磁盘或其他直接存取辅助设备设计的一种平衡查找树。在B+tree中，所有记录节点都是按键值的大小顺序存放在同一层的叶子节点上，由各叶子节点指针进行连接。
b+tree会根据指定的索引列的值排序：5,10,15,20,25,30,50,55,60,65,75,80,85,90
平衡二叉树的原理
平衡二叉树的查找性能是比较高的，但不是最高的只是接近最高性能。平衡二叉树的维护实际上代价是非常大的。通常来说，需要1次或者更多次的左旋和右旋来得到插入或更新后树的平衡性。
实例一：
当插入9这个值后，会围绕8进行一次左旋，以保证平衡
**hash索引
命令alter table user add index hash_gender using hash(gender);
会发现name的索引类型还是为btree；这是innodb的特点，当前的name可以成为自适应哈希索引；是因为完全由InnoDB自己决定，不需要DBA人为干预。它是通过缓冲池中的B+树构造而来，且不需要对整个表建立哈希索引，因此它的数据非常快
如下：图 MySQL根据字段值创建对应的索引然后会以零散的方式存放
哈希索引值包含哈希值和行指针，而不存储字段值，所以不能使用索引的值避免数据库对于行的 读取(using index)。不过访问内存中的行的速度很快，索引大部分情况下这点并不影响；
哈希索引数据并不是按照索引值顺序存储的，所以也就无法用于排序。
哈希索引不能利用部分索引来查询(联合索引的情况) =》 因为哈希索引是通过内容计算到的哈希值。
哈希如果遇到大量的hash值相等的时候，一些索引维护操作的代价会很高
