深挖MySQL —— 索引结构与优化（二）索引组织表

       上一篇我们聊了B+树是什么，innodb为什么选择了B+树，接下来我们来看看innodb是如何使用B+树这个数据结构来组织数据的。

        聚集索引

        聚集索引，也有的书将它翻译为聚簇索引。innodb的数据按照主键（没有主键则为第一个设置的候选码，没有候选码则为隐藏字段rowid）的顺序存放在B+树中，所以innodb存储引擎表又叫索引组织表。在这颗B+树中，叶子节点存放行记录数据，这颗树的key就是聚集索引，叶子节点称为数据页。聚集索引的特性决定了索引组织表中的数据也是索引的一部分，也决定了查询优化器倾向于采用聚集索引来查询数据。

        结合上一篇聊的B+，我们还能得出聚集索引的两个限制：

        1）索引的长度不能超过8k，严格地说是不能超过<8k，因为聚集索引是以主键为key来组织B+树的，当索引长度过长时，一个节点就变成只能存放1个key值，此时B+树退化为链表：一个key就只剩一个分叉了。

        2）页上的数据不能是物理顺序存放的，数据库是有CRUD操作的，当数据在页中按物理顺序存放时，若是插入了主键值在两个主键间的行时，后面部分的数据将务必需要重新排列，维护成本极高，这也是上一篇B+树特点第4点“叶子节点里看起来是个数组，其实真实结构是个链表”的原因。

        辅助索引

        辅助索引又称二级索引，用过MySQL的同学肯定知道innodb表肯定不仅仅只有一个聚集索引。理论上innodb此外还可以设置至多64辅助索引，以下是官网原文：

This section describes limits for InnoDB tables, indexes, tablespaces, and other aspects of the InnoDB storage engine.

A table can contain a maximum of 1017 columns. Virtual generated columns are included in this limit.

A table can contain a maximum of 64 secondary indexes

        辅助索引的结构大致和聚集索引相同，区别在于叶子节点存放的不是行数据而是索引键值和一个书签bookmark，书签告诉innodb在哪里可以找到与索引对应的行数据 （其实就是主键）。使用辅助索引查询数据时，通常是根据索引找到书签，然后根据主键找到真实数据。

        自适应hash索引

        除了B+树数据结构，在innodb缓冲里面其实也是有使用hash表数据结构的。innodb会监控表上个索引页的查询。如果引擎觉得建立hash索引会代来速度的提升，会建立hash索引，称为自适应hash索引（Adaptive Hash Index AHI）。AHI通过缓冲池的B+树页构造而来，而且不是对整张表构建，而是根据访问频率和模式来自动的为某些热点数据构建，所以构建的速度特别快。使用命令show engine innodb status可以观察到AHI的使用情况。

        AHI是非常好的优化模式，设计思想是通过数据库自优化的。因此，我们通常考虑查询优化指的一般是针对B+树索引，而不是调整AHI（当然你想调整的话页没有法调整）。

如有错误，敬请斧正；欢迎转载，但请务必注明出处；最后，在此向神奇的海螺保证，绝不太监！！！