5.1 InnoDB存储引擎索引概述
InnoDB支持两种常见的索引
- B+树索引
- 哈希索引（自适应的，会根据表的使用情况自动生成，不能人为干预）
一个常被忽略的问题：
B+树索引并不能找到一个给定键值的具体行，只能找到被查数据所在的页，然后数据库将此页读入内存，再在页中查找最后得到数据。
5.2 二分查找法
每页Page Directory中的槽是按照主键的顺序存放的，对于某一条具体记录的查询是通过对Page Directory进行二分查找得到的。
5.3 平衡二叉树
二叉查找树
制杖二叉查找树
若想最大性能的构造一个二叉查找树，需要这棵树是平衡的 — 平衡二叉树，或称AVL树，平衡二叉树并不一定是最优二叉树。
维护平衡二叉树必然有一定的开销， 不过多用于内存结构对象中，所以开销相对较小
5.4 B+树
B+树
5.4.1 B+树的插入操作
B+树插入情况
插入28
插入70
插入95
5.4.2 B+树的删除操作
B+树用填充因子（fill factor）来控制树的删除变化，50%是填充因子可设的最小值。
B+树删除
删除70
删除60
5.5 B+树索引
B+索引在数据库中一个特点就是其高扇出性，在数据库中，高度一般都是在2-3层，也就是查询一个数据，最多只需要2-3次IO。
B+树索引可以分为聚集索引（clustered index）和辅助聚集索引（secondary index）。其不同点是，叶节点存放的是否是一整行的信息。
5.5.1 聚集索引
InnoDB存储引擎表是索引组织表，即表中数据按照主键顺序存放。而聚集索引就是按照每张表的主键构造一棵B+树，叶节点中存放的整张表的行记录数据，因此也让聚集索引的叶节点成为数据页。聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。同B+树一样，每个数据页都通过一个双向链表来进行链接。
- 聚集索引可以让我们在索引的叶节点上直接找到数据；
- 此外由于定义了数据的逻辑顺序，聚集索引能够特别快的访问针对范围值的查询，查询优化器能够快速发现某一段范围的数据页需要扫描。
- 聚集索引对于主键的排序查找和范围查找速度非常快
5.5.2 辅助索引（非聚集索引）
页级别不包含行的全部数据。叶节点除了包含键值以外，每个叶级别的索引行中还包含了一个书签，该书签用来告诉InnoDB哪里可以找到与索引相对应的行数据，实际上，辅助索引的书签就是聚集索引键。
聚集索引与辅助索引关系
5.5.3 B+树索引的管理
索引创建和删除方式
ALTER TABLE 1
ALTER TABLE 2
CREATE/DROP
目前对于索引的添加或者删除，均为创建一个临时表，把数据导入临时表，删除原表，重命名临时表，所以大表操作索引也会很费时间。
但是InnoDB Plugin开始，支持一种称为快速索引创建方法，当时只限于辅助索引，对于索引的创建，不用重新建表，而是加上一个S锁。删除时，在内部视图更新下，将辅助索引的空间标记为空，并删除MySQL内部视图上对于该表的索引定义即可。
5.6 B+树索引的使用
5.6.1 什么时候使用B+树索引
访问表中很少一部分行时，才有建表必要（高选择性）。而对于取出很多行时，没有必要建立索引。
及时高选择性的字段，但是取出大部分数据，此时不会使用索引（日期范围等情况）
5.6.2 顺序读、随机读与预读取
预读取，通过一次IO将预测会访问的多个页缓存下来
- 随机预读取。一个区中有一部分页被频繁访问，则预读本区整个区。
- 线性预读取。一个区多少页被顺序访问，则预读下个区的所有页。
很尴尬的是，预读取关闭时比开启性能还要好，InnoDB Plugin1.0.4后随机访问的预读取关了，但是线性预读取还是保留了。
当前数据库策略并不适合固态硬盘
5.6.3 辅助索引的优化使用
当辅助索引叶节点有足够数据时（比如只查询主键），数据库会使用辅助索引，但是当对主键order by 或者强制使用聚集索引，就会用回聚集索引
5.6.4 联合索引
对表上多个列做索引，按顺序使用索引列才会命中，因为单独看后面的列，并没有按顺序摆放。
5.7 哈希算法
5.7.1 哈希表
直接寻址表
哈希表
链表法解决碰撞
5.7.2 InnoDB中的哈希算法
5.7.3 自适应哈希索引
欢迎大家关注我的公众号
半亩房顶
