04 深入浅出索引（上）

索引

  索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。

索引的常见模型

  在MySQL中，索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。

哈希数组+链表

  哈希的思路很简单，把值放在数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置。如果多个key值经过哈希函数的换算，出现同一个值的情况，此时在数组对应的位置上拉出一个链表。
哈希表这种结构适用于只有等值查询的场景，不适合范围查询。

有序数组

  如果仅仅看查询效率，有序数组就是最好的数据结构了。但是，在需要更新数据的时候就麻烦了，你往中间插入一个记录就必须得挪动后面所有的记录。
  有序数组索引在等值查询和范围查询场景中的性能就都非常优秀，但是只适用于静态存储引擎，需要更新数据时需要修改更新处之后的所有记录。

二叉树

  二叉搜索树的特点是：每个节点的左儿子小于父节点，父节点又小于右儿子。
  为什么平衡二叉树不适合做索引？
  索引是存在于索引文件中，是存在于磁盘中的。因为索引通常是很大的，因此无法一次将全部索引加载到内存当中，因此每次只能从磁盘中读取一个磁盘页的数据到内存中。而这个磁盘的读取的速度较内存中的读取速度而言是差了好几个级别。
  注意，我们说的平衡二叉树结构，指的是逻辑结构上的平衡二叉树，其物理实现是数组。然后由于在逻辑结构上相近的节点在物理结构上可能会差很远。因此，每次读取的磁盘页的数据中有许多是用不上的。因此，查找过程中要进行许多次的磁盘读取操作。
而适合作为索引的结构应该是尽可能少的执行磁盘IO操作，因为执行磁盘IO操作非常的耗时。因此，平衡二叉树并不适合作为索引结构。

InnoDB 的索引模型

  每一个索引在InnoDB里面对应一棵B+树。

主键索引

  主键索引的叶子节点存的是整行数据。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。

非主键索引

  非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）。

回表

  基于非主键索引的查询，先在非主键索引树中查到主键的值，再到主键索引树中，根据主键的值，查到整行的数据，需要多扫描一棵索引树，被称为回表。

索引维护

页的分裂与合并

  页（Page）是 Innodb 存储引擎用于管理数据的最小磁盘单位。默认的页大小为 16KB，每个页中至少存储有 2 条或以上的行记录。

小结

  对于上面例子中的InnoDB表T，如果你要重建索引 k，你的两个SQL语句可以这么写：

alter table T drop index k;
alter table T add index(k);

如果你要重建主键索引，也可以这么写：

alter table T drop primary key;
alter table T add primary key(id);

我的问题是，对于上面这两个重建索引的作法，说出你的理解。如果有不合适的，为什么，更好的方法是什么？
答：