简单介绍一下索引
索引是为了帮助快速获取数据库数据的数据结构。基于数据库表创建，包含某一列的值及记录对应的地址。
对于select from employee where name = ‘abc’,如果name做了索引，索引关键字就会按照字母顺序排列，假设索引是一个链表的数据结构，每个节点存储了数据库关键字以及数据的地址。查询时只需要顺序遍历，比如说第501个name是abc，502不是，name就可以停止遍历了，因为是按顺序存储的。查询时需要的数据都在一块，不需要做全表扫描，所以比较快。
在MySQL中，主要有四种类型的索引，分别为：B-Tree索引，Hash索引，Fulltext索引和R-Tree索引
用什么数据结构做索引
比如用链表做索引，数据插入速度快，但是查询时间复杂度比较高。不合适
比如用数组+二分查找做索引，数据查询时间复杂度低，但是插入删除的复杂度又很高，不合适
综合考虑，使用树结构做索引。
用二叉树或者红黑树做索引？查询复杂度log2(n) 但是由于数据库存储在磁盘里，要降低时间，更少的io操作是关键。逻辑结构上相近 的节点 在物理结构上 可能会差很远。无法充分利用磁盘预读功能
局部性原理与磁盘预读：
由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。
这样做的理论依据是计算机科学中著名的局部性原理：
当一个数据被用到时，其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高I/O效率.
红黑树这种结构，h明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O(h)，效率明显比B-Tree差很多
B树和B+树
B树：有序数组+平衡多叉树；
B+树：有序数组链表+平衡多叉树；
B+树的关键字全部存放在叶子节点中，非叶子节点用来做索引，而叶子节点中有一个指针指向一下个叶子节点。做这个优化的目的是为了提高区间访问的性能。而正是这个特性决定了B+树更适合用来存储外部数据。
B+树还有一个最大的好处，方便扫库，B树必须用中序遍历的方法按序扫库
数据库索引采用B+树的主要原因是B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。正是为了解决这个问题，B+树应运而生。B+树只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作（或者说效率太低）。
B树
B+树
用手机号适合做主键吗
1永远选择一个和业务无关的字段作为主键，比如用手机号作为主键，可能当时手机号不会重复，业务的需求总是多变的，主键使用一个业务字段难免使得业务复杂化。
2从数据库索引的设计方面说，一个聚簇索引，关键字占用空间越小越好，因为一个b+树一个节点上存储的空间是有限的，索引越小，存放的数量就越多，并且innodb中，InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。
主键小可以减少查询时的io频次。
3
InnoDB使用聚集索引，数据记录本身被存于主索引（一颗B+Tree）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）。这样就会形成一个紧凑的索引结构，近似顺序填满。由于每次插入时也不需要移动已有数据，因此效率很高，也不会增加很多开销在维护索引上。此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。
所以手机号不适合
参考文章
1.MySQL索引背后的数据结构及算法原理（超赞的文章，2011年写的文章，厉害……）
2.从B树、B+树、B*树谈到R 树(这篇文章作者也是好厉害，其博客访问量达千万)
3.浅谈算法和数据结构: 十 平衡查找树之B树，而这篇博文里有B树和B+树插入元素的过程GIF图，超赞，有助于对B树和B+树的理解！
4.b+树的详细结构
