B-tree索引
mysql中btree存储的物理文件大多是balance tree（平衡树）结构来存储的。也就是实际存储数据放在叶节点。而且任何一个叶节点的最短路径都一样。可能各种数据库的在存放自己的btree索引时会对存储结构做改动。例如：innodo的btree实际上是b+tree，在原有的叶节点除了存放索引等关键信息外，还存储了后一个叶节点的指针信息。这是出于加快检索多个相邻的叶节点的效率考虑的。
主键索引 ：
叶节点存放的，除了主键的数据外，还有其他字段数据的以主键的有序排列。所以，通过主键来访问数据效率是非常高的。
btree索引：
不仅在叶节点存放索引的相关信息，也有主键值。
通过secondary index访问，通过相应的索引检索到leaf node，再通过leaf node中存放的主键信息来获取数据行。

Image.png

MyISAM的索引形式是b+tree,leaf node存放的是数据记录地址。可以看的出来，myisam的索引文件仅仅保存数据记录的地址
MyISAM索引文件和数据文件是分离的
它的主索引和辅助索引在结构上没有区别，只是主索引要求唯一，而辅助索引可以重复。
MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。
MyISAM中首先按照b+tree搜索算法搜索索引，如果指定的key存在，则去除data域，再通过data域的值为地址去读取相应的数据记录。

Image.png

InnoDB的数据文件本身就是索引文件。
InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。
这种索引叫做聚集索引。
因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键
所以，innodb检索直接通过主键非常地高效。

与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说：innodb的辅助索引会引用主键作为自己的data域。
聚集索引这种实现方式使得按主键的搜索十分高效。

innodb的主键不宜过长，以为辅助索引会引用主索引。过长的主索引会导致辅助索引变大。
根据b+tree的特性，自增字段可以做到和b+tree的leaf node分裂顺序一致。所以用自增字段做innodb的主键是一个很好的选择

Image.png

标准的B+tree
一个平衡的多叉树，根节点到各叶节点的高度差不超过1，同层级节点之间有指针相互衔接。
这种数据结构，从根节点到叶节点的检索效率相当，基于索引的顺序扫描，也可以利用双向指针快速顺序移动。效率很高。
所以，B+树索引被广泛应用于数据库、文件系统等场景。
顺便说一下，xfs文件系统比ext3/ext4效率高很多的原因之一就是，它的文件及目录索引结构全部采用B+树索引，而ext3/ext4的文件目录结构则采用Linked list, hashed B-tree、Extents/Bitmap等索引数据结构，因此在高I/O压力下，其IOPS能力不如xfs。

Image.png

2.同理，无法进行数据的排序操作，以及 like ‘xxx%’这样的模糊查询（模糊查询，本质上还是范围查询）

3.不能利用部分索引查询
因为它是计算组合索引合并后的hash值，而不是单独计算。对于一个或者多个的组合索引进行查询的时候，hash索引无法被利用。

4在任何时候都不能避免扫描全表
由于不同的hash索引存在相同的hash值，所以即使满足某个hash值的记录条数，也无法直接在hash索引中完成查询。还是要通过表中的数据进行实际的比较。

5.在遇到大量的重复键，就是hash值相等的情况下，性能不一定比btree高。
因为存在hash冲撞。

在MySQL中，只有HEAP/MEMORY引擎表才能显式支持哈希索引（NDB也支持，但这个不常用），
InnoDB引擎的自适应哈希索引（adaptive hash index）不在此列，因为这不是创建索引时可指定的。
还需要注意到：HEAP/MEMORY引擎表在mysql实例重启后，数据会丢失。

适合用hash索引
SELECT … FROM t WHERE C1 = ?; — 仅等值查询
大多数情况下，都会有范围查询，模糊查询这些，用btree索引就行。