笔记04深入浅出索引

索引模型

索引的出现是为了提高查询效率，但是实现索引的方式却有很多种，所以这里也就引入了索引模型的概念

适用于等值查询的哈希表

把值放在数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置。

哈希冲突的解决策略

图中四个ID_card_n的值并不是递增的，这样做的好处是增加新的User时速度会很快，只需要往后追加。但缺点是，因为不是有序的，所以哈希索引做区间查询的速度是很慢的。

适用于静态存储引擎的有序数组

很显然，这个索引结构支持范围查询。你要查身份证号在[ID_card_X, ID_card_Y]区间的
User，可以先用二分法找到ID_card_X（如果不存在ID_card_X，就找到大于ID_card_X的第一
个User），然后向右遍历，直到查到第一个大于ID_card_Y的身份证号，退出循环

缺点：更新数据，你往中间插入一个记录就必须得挪动后面所有的记录，成本太高。

二叉搜索树

每个节点的左儿子小于父节点，父节点又小于右儿子。这样如果你要查ID_card_n2的话，按照图中的搜索顺序就是按照UserA ->UserC->UserF ->User2这个路径得到。这个时间复杂度是O(log(N))。为了保证是搜索效率，必须保证是平衡二叉树(左子树和右子树的高度相差不过1).

缺点：数据量大的时候，在磁盘中访问的数据块较多，查询速率慢。(一棵100万节点的平衡二叉树，树高20。一次查询可能需要访问20个数据块。在机械硬盘时代，从磁盘随机读一个数据块需要10 ms左右的寻址时间。也就是说，对于一个100万行的表，如果使用二叉树来存储，单独访问一个行可能需要20个10 ms的时间，查询慢。)

Innodb的索引模型

表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表。InnoDB使用了B+树索引模型，所以数据都是存储在B+树中的。

根据建立的表：

mysql> create table T(
id int primary key,
k int not null,
name varchar(16),
index (k))engine=InnoDB;

对应的这里有以 主键索引ID 和 非主键索引K
主键索引的叶子节点存的是整行数据。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。
非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）。

区别
如果语句是select *fromTwhere ID=500，即主键查询方式，则只需要搜索ID这棵B+树；
如果语句是select *fromTwhere k=5，即普通索引查询方式，则需要先搜索k索引树，得到ID的值为500，再到ID索引树搜索一次。这个过程称为回表。也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询

索引维护

以上面这个图为例，如果插入新的行ID值为700，则只需要在R5的记录后面插入一个新记录。
如果新插入的ID值为400，就相对麻烦了，需要逻辑上挪动后面的数据，空出位置。
而更糟的情况是，如果R5所在的数据页已经满了，根据B+树的算法，这时候需要申请一个新的数据页，然后挪动部分数据过去。这个过程称为页分裂。在这种情况下，性能自然会受影响。
除了性能外，页分裂操作还影响数据页的利用率。原本放在一个页的数据，现在分到两个页中，整体空间利用率降低大约50%。

哪些场景下应该使用自增主键，而哪些场景下不应该

自增主键	保证有序插入，普通索引的叶子节点小，占据存储空间更小	大多数时候应该采用自增主键作为索引
业务字段	无法保证插入有序，普通索引的叶子节点可能较大，存储空间也可能较大	只有一个索引必须是唯一索引的时候可采用(KV场景)