经常可能发生，某个SQL查询比较慢，分析完原因后，可能就会想到“给某个字段加个索引”这样的方案。
索引的出现就是为了提高数据查询的效率。
索引的常见模型
实现索引的方式有很多种，所以这里也就引入了索引模型。比较常见的，哈希表、有序数组和搜索树。
哈希表以键值对存储数据，只要输入对应的key，就可以找到对应的value。哈希的思路，把值放到数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置。
可能多个key值经过哈希函数的换算会出现同一个值的情况。处理这种情况的一种方法是，拉出一个链表。
图中User2和User4根据身份证号算出来的值都是N，但是没关系，后面有链表，按顺序遍历，找到User2。
四个ID_card_n的值并不是递增的，这样做的好处是增加新的User时速度会很快。但缺点是因为不是有序的，所以哈希索引做区间查询的速度是很慢的。假如想查找身份证号在[ID_card_X, ID_card,Y]这个区间的所有用户，就必须全部扫描一遍。
所以哈希表这种结构适用于只有等值查询的场景，比如Memcached及其他一些NoSQL引擎。
而有序数组在等值查询和范围查询场景中的性能都非常优秀。
这里假设身份证号没有重复，这个数组是按照递增的顺序保证的。如果要查ID_card_n2对应的名字，用二分法就可以快速得到，这个时间复杂度是O(log(N))。
同时很显然支持范围查询，查找身份证号在[ID_card_X, ID_card_Y]这个区间的所有用户，先用二分法找到ID_card_X（如果不存在，就找到大于ID_card_X的第一个User），然后向右遍历，直到查到第一个大于ID_card_Y的，退出循环。
但是有序数组的缺点在于更新数据的时候，往中间插入一个记录就必须得挪动后面所有的记录，成本太高。
所以有序数组只适用于静态存储引擎。（比如2017年某个城市所有人口信息，这类不会再修改的数据）
二叉搜索树的特点事：每个节点的左儿子小于父节点，父节点又小于右儿子。
如果要查ID_card_n2, 就需要 UserA -> UserC -> UserF -> User2 这个路径，时间复杂度为O(log(N))。
二叉树搜索效率最高，但实际上大多数数据库存储并不使用二叉树。因为索引不止存在内存中，还要写在磁盘上。
一棵100万个节点的平衡二叉树，树高20。一次查询可能需要访问20个数据块。从磁盘随机读一个数据块需要10ms左右的寻址时间，对于100万行的表，单独访问一个行可能需要20个10ms的时间，这个查询可真够慢的。
为了让一个查询尽量少读磁盘，就必须尽量少访问数据块。就应该使用N叉树。N 取决于数据块的大小。
InnoDB的一个整数字段索引为例，这个N差不多是1200。高是4时就可以存1200的三次方个节点，已经17亿了。树根的数据块总是在内存中，查找一个值最多只需要访问3次磁盘。其实，树的第二层也有很大概率在内存中。树的第二层也有很大概率中，那访问此判断的平均次数就更少了。
N叉树由于读写上的性能优点，被广泛运用到数据库引擎中。
数据库底层存储的核心就是基于这些数据模型的。
MySQL中，不同存储引擎的索引的工作方式并不一样。即使多个存储引擎支持同一种类型的索引，其底层实现也可能不同。
以InnoDB的索引模型为例
InnoDB中，表都是根据主键顺序以索引的形式存放，这种存储方式的表称为索引组织表。InnoDB使用B+树索引模型，所以数据都是存储在B+树中的。
每一个索引在InnoDB里面对应一棵B+树。
假设，有一个主键列为ID的表，表中有字段k，并且在k上有索引。
mysql> create table T(
id int primary key,
k int not null,
name varchar(16),
index (k))engine=InnoDB;
表中R1~R5的(ID, k)值分别为(100, 1) (200, 2) (300, 3) (500, 5) (600, 6)
从图中可以看出，索引类型分为主键索引和非主键索引。
主键索引的叶子节点存的是整行数据，InnoDB里，主键索引也被称为聚簇索引（clustered index）。非主键索引的叶子节点内容是主键的值，InnoDB里面也称为二级索引(secondary index)。
基于主键索引和普通索引的查询有什么区别？
如果语句是select * from T where ID=500 即主键查询方式，则只需要搜索ID这棵B+树。
如果语句是select * from T where k = 5 即普通索引查询方式，则需要先搜索k索引树，得到ID的值为500，再到ID索引树搜索一次。这个过程称为回表。
也就是，非主键索引的查询会多扫描一棵索引树，因为应该尽量使用主键查询。
索引维护
以上图为例，当插入新值的时候，需要维护索引有序性。如果插入新的行ID值为700，则只需要在R5的记录后面插入一个新记录。如果新插入的ID为400，就需要逻辑上挪动后面的数据，空出位置。
而如果R5所在的数据页已经满了，根据B+树的算法，这时候需要申请一个新的数据页，然后挪部分数据过去。这个过程称为页分裂。在这种情况下，性能自然会受影响。
页分裂还影响利用率，原本一个页的数据，现在放入两个页，整体空间利用率降低50%。
有分裂就有合并。当相邻两个页删除了数据，利用率很低之后会将数据页做合并。合并的过程，可以认为是分裂过程的逆过程。
自增主键是指自增列上定义的主键，在建表语句中一般是这么定义：NOT NULL PRIMARY KEY AUTO_INCREMENT
插入新记录的时候可以不指定ID的值，系统会自动获取当前ID最大值加1作为下一条记录的ID值。都是追加，不会挪动其他其他记录，也不会触发叶子节点的分裂。
有业务逻辑的字段做主键，往往不容易保证有序插入，这样写数据成本相对较高。
除了考虑性能外，还可以从存储空间的角度来看。假设表中有一个唯一字段，比如字符串类型的身份证号，那应该用身份证号做主键，还是用自增字段做主键？
由于每个非主键索引的叶子节点都是主键的值。如果用身份证号做主键，那么每个二级索引的叶子节点占用约20个字节，而如果用整型做主键，则只有4个字节，如果是长整型则是8个字节。
显然主键越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。
所以从性能和存储空间角度来看，自增主键是更合理的选择。
适合用业务字段直接做主键的：
1.只有一个索引
2.该索引必须是唯一索引
这时就优先考虑上一段提到的“尽量使用主键查询”原则，直接将这个索引设为主键，可以避免每次查询需要搜索两棵树。
小结
B+树能配合磁盘的读写特性，减少单次查询的磁盘访问次数。
对于上面例子的表T，如果要重建索引k:
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);
通过两个alter语句重建索引k，以及两个alter语句重建主键索引是否合理？
为什么要重建，因为索引可能因为删除，或者页分裂等原因，导致数据页有空洞，重建索引的过程会创建一个新的索引，把数据按顺序插入，这样页面的利用率最高，也就是索引更紧凑、更省空间。
重建索引k的做法是合理的，可以达到省空间的目的。到那时重建主键的过程不合理，不论是删除主键还是创建主键，都会将整个表重建。所以连着执行这两个语句的话，第一个语句就白做了。
这两个语句，可以用：alter table T engine=InnoDB 代替。
