一、InnoDB 索引概述
1. B+树索引
2. 全文索引
3. 哈希索引
哈希索引是自适应的，InnoDB 会根据表的使用自动生成哈希索引，不能人为的干预是否在一张表中生成哈希索引。
B+树索引是传统意义上的索引，也是目前关系型数据库中查找最常用和最有效的索引。B+树索引的构造类似于二叉树，根据键值迅速找到数据。另外，B+树并不能直接找到一个给定键值的具体行，B+树索引只是被查找数据行所在的页，然后数据库通过把页读到内存中进行查找，最后找到具体的数据。
二、B+树的索引
B+树索引的本质就是B+树在数据库中的实现。但是B+索引在记录时最多只需要2到4次IO。因为当前一般的机械磁盘每秒至少可以做100次IO，2～4次的IO意味着查询时间只需0.02～0.04秒。 数据库中的B+树索引可以分为聚集索引（clustered inex）和辅助索引（secondary index），但是不管是聚集还是辅助的索引，其内部都是B+树的，即高度平衡的，叶子节点存放着所有的数据。
聚集索引与辅助索引不同的是，叶子节点存放的是否是一整行的信息。聚集索引存放的一个完整的表结构和数据，辅助索引存放的是某个字段和对应主键的指针。
InnoDB存储引擎的表是索引组织表，即表中数据按照主键顺序存放。而聚集索引就是按照表中的主键构造一颗B+树，同时叶子节点存放的就是整张表的行记录数据，所以也将聚集索引的叶子节点称为数据页。聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。
同B+树结构一样，每个数据页都通过一个双向链表来进行链接。由于实际的数据页只能按照一棵B+树进行排序，因此每张表只能拥有一个聚集索引。在多数情况下，查询优化器倾向于采用聚集索引。因为聚集索引能够在B+树索引的叶子节点上直接找到数据。此外，由于定义了数据的逻辑顺序，聚集索引能够特别快地访问针对范围值的查询。查询优化器能够快速发现某一段范围的数据页需要扫描。
通过对非数据页节点的分析，可以发现数据页上存放的是完整的每行的记录，而在非数据页的索引页中，存放的仅仅是键值及指向数据页的偏移量，而不是一个完整的行记录。
聚集索引的存储并不是物理上连续的，而是逻辑上连续的。这其中有两点：一是页通过双向链表链接，页按照主键的顺序排序，而主键的排列顺序是固定的，所以需要非叶子节点的动态分裂（保证从左读到右是升序的）。这涉及到内存的连续分配，总之内存并不是顺序分配，而是通过链表链接（指针全部存放在非叶子节点）；另一点是每个页中的记录也是通过双向链表进行维护的，物理存储上可以同样不按照主键存储。
聚集索引的另一个好处是，它对于主键的排序查找和范围查找速度非常快。叶子节点的数据就是用户所要查询的数据。如用户需要查询一张注册用户的表，查询最后注册的10位用户，由于B+树索引是双向链表的，用户可以快速找到最后一个数据页，并取出10条记录。
另一个是范围查询（range query），即如果要查找主键某一范围内的数据，通过叶子节点的上层中间节点就可以得到页的范围，之后直接读取数据页即可。
包含键值以外，每个叶子节点中的索引行中还包含了一个书签（bookmark）。该书签用来告诉InnoDB存储引擎哪里可以找到与索引相对应的行数据。由于InnoDB存储引擎表是索引组织表，因此InnoDB存储引擎的辅助索引的书签就是相应行数据的聚集索引键。
辅助索引的存在并不影响数据在聚集索引中的组织，因此每张表上可以有多个辅助索引。当通过辅助索引来寻找数据时，InnoDB存储引擎会遍历辅助索引并通过叶级别的指针获得主键，然后再通过主键索引来找到一个完整的行记录。举例来说，如果在一棵高度为3的辅助索引树中查找数据，那需要对这棵辅助索引树遍历3次找到指定主键，如果聚集索引树的高度同样为3，那么还需要对聚集索引树进行3次查找，最终找到一个完整的行数据所在的页，因此一共需要6次逻辑IO访问以得到最终的一个数据页。
三、哈希索引
复杂度为O(1),仅需一次就能定位数据。是一种优化模式。只能适用于 = 模式。
InnoDB存储引擎会监控对表上各索引页的查询。如果观察到建立哈希索引可以带来速度提升，则建立哈希索引，称之为自适应哈希索引（Adaptive Hash Index，AHI）。AHI是通过缓冲池的B+树页构造而来，因此建立的速度很快，而且不需要对整张表构建哈希索引。InnoDB存储引擎会自动根据访问的频率和模式来自动地为某些热点页建立哈希索引。启用AHI后读写速度可以提高2倍，辅助索引可以提高5倍。
AHI有一个要求，即对这个页的连续访问模式必须是一样的。例如对联合索引(a,b)，每次索引的数据都必须是相同的，否则就不会建立AHI。
AHI还有以下要求：
以该模式访问了100次
页通过该模式访问了N次，其中N=页中记录*1/16