参考地址：
javaGuide
数据库两大神器【索引和锁】
# MySQL B+树索引和哈希索引的区别
浅谈MySQL的B树索引与索引优化
1.索引的基础知识
首先Mysql的基本存储结构是页(记录都存在页里边)：
- 各个数据页可以组成一个双向链表
- 而每个数据页中的记录又可以组成一个单向链表
- 每个数据页都会为存储在它里边儿的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录
- 以其他列(非主键)作为搜索条件：只能从最小记录开始依次遍历单链表中的每条记录。
所以说，如果我们写select * from user where username = 'Java3y'这样没有进行任何优化的sql语句，默认会这样做：
- 定位到记录所在的页
- 需要遍历双向链表，找到所在的页
- 从所在的页内中查找相应的记录
- 由于不是根据主键查询，只能遍历所在页的单链表了
很明显，在数据量很大的情况下这样查找会很慢！
2.索引提高搜索速度
索引做了些什么可以让我们查询加快速度呢？
其实就是将无序的数据变成有序(相对)：
要找到id为8的记录简要步骤：
很明显的是：没有用索引我们是需要遍历双向链表来定位对应的页，现在通过“目录”就可以很快地定位到对应的页上了！
其实底层结构就是B+树，B+树作为树的一种实现，能够让我们很快地查找出对应的记录。
索引实现参考地址
3.索引降低增删改的速度
B+树是平衡树的一种。
平衡树：它是一棵空树或它的左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树。
如果一棵普通的树在极端的情况下，是能退化成链表的(树的优点就不复存在了)
B+树是平衡树的一种，是不会退化成链表的，树的高度都是相对比较低的(基本符合矮矮胖胖(均衡)的结构)【这样一来我们检索的时间复杂度就是O(logn)】！从上一节的图我们也可以看见，建立索引实际上就是建立一颗B+树。
- B+树是一颗平衡树，如果我们对这颗树增删改的话，那肯定会破坏它的原有结构。
- 要维持平衡树，就必须做额外的工作。正因为这些额外的工作开销，导致索引会降低增删改的速度。
4.B+树索引和哈希索引的区别
一个经典的B+树索引数据结构见下图：
B+树是一个平衡的多叉树，从根节点到每个叶子节点的高度差值不超过1，而且同层级的节点间有指针相互链接。
在B+树上的常规检索，从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动，而且基于索引的顺序扫描时，也可以利用双向指针快速左右移动，效率非常高。
因此，B+树索引被广泛应用于数据库、文件系统等场景。
哈希索引的示意图则是这样的：
简单地说，哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。
从上面的图来看，B+树索引和哈希索引的明显区别是：
如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；
从示意图中也能看到，如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；
同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；
哈希索引也不支持多列联合索引的最左匹配规则；
B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。
5.B树与B+树
1.B树解决了什么问题
如果抛开维护操作，那么B树就像一棵“m叉搜索树”（m是子树的最大个数），时间复杂度为O(logm(n))。然而，B树设计了一种高效简单的维护操作，使B树的深度维持在约log(ceil(m/2))(n)~logm(n)之间，大大降低树高。
再次强调：
不要纠结于时间复杂度，与单纯的算法不同，磁盘IO次数才是更大的影响因素。读者可以推导看看，B树与AVL的时间复杂度是相同的，但由于B树的层数少，磁盘IO次数少，实践中B树的性能要优于AVL等二叉树。
同二叉搜索树类似，每个节点存储了多个key和子树，子树与key按顺序排列。
页表的目的是扩展内存+加速磁盘读写。一个页（Page）通常4K（等于磁盘数据块block的大小，见inode与block的分析），从磁盘读写的角度出发，操作系统每次以页为单位将内容从磁盘加载到内存（以摊分寻道成本），修改页后，再择期将该页写回磁盘。考虑到页表的良好性质，可以使每个节点的大小约等于一个页（使m非常大），这每次加载的一个页就能完整覆盖一个节点，以便选择下一层子树；对子树同理。对于页表来说，AVL（或RBT）相当于1个key+2个子树的B树，由于逻辑上相邻的节点，物理上通常不相邻，因此，读入一个4k页，页面内绝大部分空间都将是无效数据。
假设key、子树节点指针均占用4B，则B树节点最大m * (4 + 4) = 8m B；页面大小4KB。则m = 4 * 1024 / 8 = 512，一个512叉的B树，1000w的数据，深度最大 log(512/2)(10^7) = 3.02 ~= 4。对比二叉树如AVL的深度为log(2)(10^7) = 23.25 ~= 24，相差了5倍以上。震惊！B树索引深度竟然如此！
另外，B树对局部性原理非常友好。如果key比较小（比如上面4B的自增key），则除了页表的加成，缓存还能进一步预读加速。美滋滋~
2.B树的剩余问题
然而，如果要实际应用到数据库的索引中，B树还有一些问题：
- 未定位数据行
- 无法处理范围查询
问题1
数据表的记录有多个字段，仅仅定位到主键是不够的，还需要定位到数据行。有3个方案解决：
- 直接将key对应的数据行（可能对应多行）存储在节点中。
- 数据行单独存储；节点中增加一个字段，定位key对应数据行的位置。
- 修改key与子树的判断逻辑，使子树大于等于上一key小于下一key，最终所有访问都将落于叶子节点；叶子节点中直接存储数据行或数据行的位置。
方案1中，数据行通常非常大，存储数据行将减少页面中的子树个数，m减小树高增大。假设数据行占用200B，可忽略组织B树的指针，则新的m = 4 * 1024 / 200 = 20.48 ~= 21，深度最大 log(21/2)(10^7) ~= 7。增加了一倍以上的IO，不考虑。
方案2中，节点增加了一个字段。假设是4B的指针，则新的m = 4 * 1024 / 12 = 341.33 ~= 341，深度最大 log(341/2)(10^7) = 3.14 ~= 4。与3差别不大，可以考虑。
方案3的节点m与深度不变，但时间复杂度变为稳定的O(logm(n))。考虑。
问题2
实际业务中，范围查询的频率非常高，B树只能定位到一个索引位置（可能对应多行），很难处理范围查询。给出2种方案：
- 不改动：查询的时候先查到左界，再查到右界，然后DFS（或BFS）遍历左界、右界之间的节点。
- 在“问题1-方案3”的基础上，由于所有数据行都存储在叶子节点，B树的叶子节点本身也是有序的，可以增加一个指针，指向当前叶子节点按主键顺序的下一叶子节点；查询时先查到左界，再查到右界，然后从左界到有界线性遍历。
乍一看感觉方案1比方案2好——时间复杂度和常数项都一样，方案1还不需要改动。但是别忘了局部性原理，不管节点中存储的是数据行还是数据行位置，方案2的好处在于，叶子节点连续存储，对页表和缓存友好。而方案1则面临节点逻辑相邻、物理分离的缺点。
3.B+树
综上，问题1的方案2与问题2的方案1可整合为一种方案（基于B树的索引），问题1的方案3与问题2的方案2可整合为一种（基于B+树的索引）。实际上，数据库、文件系统有些采用了B树，有些采用B+树。
主要变动如上所述：
修改key与子树的组织逻辑，将索引访问都落到叶子节点
按顺序将叶子节点串起来（方便范围查询）
6.索引优化
1.优先使用自增key作为主键
前面的分析中，假设用4B的自增key作为索引，则m可达到512，层高仅有3。使用自增的key有两个好处：
1.自增key一般为int等整数型，key比较紧凑，这样m可以非常大，而且索引占用空间小。最极端的例子，如果使用50B的varchar（包括长度），那么m = 4 * 1024 / 54m = 75.85 ~= 76，深度最大 log(76/2)(10^7) = 4.43 ~= 5，再加上cache缺失、字符串比较的成本，时间成本增加较大。同时，key由4B增长到50B，整棵索引树的空间占用增长也是极为恐怖的（如果二级索引使用主键定位数据行，则空间增长更加严重）。
2.自增的性质使得新数据行的插入请求必然落到索引树的最右侧，发生节点分裂的频率较低，理想情况下，索引树可以达到“满”的状态。索引树满，一方面层高更低，一方面删除节点时发生节点合并的频率也较低。
2.最左前缀匹配
在mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配，示例：
对列col1、列col2和列col3建一个联合索引
KEY index_col1_col2_col3 on test(col1,col2,col3);
联合索引 index_col1_col2_col3 实际建立了(col1)、(col1,col2)、(col,col2,col3)三个索引。
SELECT * FROM table WHERE col1="1" AND clo2="2" AND clo4="4"
上面这个查询语句执行时会依照最左前缀匹配原则，检索时会使用索引(col1,col2)进行数据匹配。索引的字段可以是任意顺序的。
3.=、in自动优化顺序
不需要考虑=、in等的顺序，mysql会自动优化这些条件的顺序，以匹配尽可能多的索引列。
如有索引(a, b, c, d)，查询条件c > 3 and b = 2 and a = 1 and d < 4与a = 1 and c > 3 and b = 2 and d < 4等顺序都是可以的，MySQL会自动优化为a = 1 and b = 2 and c > 3 and d < 4，依次命中a、b、c。
4.索引列不能参与计算
有索引列参与计算的查询条件对索引不友好（甚至无法使用索引），如from_unixtime(create_time) = '2014-05-29'。
原因很简单，如何在节点中查找到对应key？如果线性扫描，则每次都需要重新计算，成本太高；如果二分查找，则需要针对from_unixtime方法确定大小关系。
因此，索引列不能参与计算。上述from_unixtime(create_time) = '2014-05-29'语句应该写成create_time = unix_timestamp('2014-05-29')。
5.能扩展就不要新建索引
如果已有索引(a)，想建立索引(a, b)，尽量选择修改索引(a)为索引(a, b)。
新建索引的成本很容易理解。而基于索引(a)修改为索引(a, b)的话，MySQL可以直接在索引a的B+树上，经过分裂、合并等修改为索引(a, b)。
6.不需要建立前缀有包含关系的索引
如果已有索引(a, b)，则不需要再建立索引(a)，但是如果有必要，则仍然需考虑建立索引(b)。
7.选择区分度高的列作索引
很容易理解。如，用性别作索引，那么索引仅能将1000w行数据划分为两部分（如500w男，500w女），索引几乎无效。
区分度的公式是count(distinct