剖析mysql底层索引_如何理解Mysql索引以及它的底层原理？

数据库索引解决的是如何在超大规模数据量时如何快速定位数据的问题。而任何数据结构和算法都是逼出来的：

在大部分时候，我们操作的数据集合都很小，比如尺寸在几十到几百之间，可以放到内存中。在这种数据量级下，如果只是偶尔查一次，完全可以把它们存贮到一个数组(array)中，查找的时候按顺序搜索就好了，这样的代码写起来简直很难有bug。

如果需要频繁查找，则一个最直接的办法是将数据按照查找使用的key存储到hash表中。虽说占点儿内存，但老板又不在乎这个，查得快就好啊。而且hash表是编程语言内置的，使用起来既简单又方便，还不容易出错，棒棒哒。

突然有一天，运营平台告诉你需要按照时间范围查找数据，这下子hash表不好使了，咋办呢？你突然想到不是还有有序数组嘛，二分查找的性能O(lgN)，虽说比hash表的O(1)差一点儿，但在大部分情况下也够用了，而且查找性能更加稳定，不会像hash那样偶尔出现O(N)的情况。你要做的就是把key和value对应存储到两个有序数组中(参考C#中的SortedList)。

随着业务中插入删除的需求越来越多了，你慢慢的发现，有序数组虽然查找起来很快，但修改起来性能好差。这是你想到一个特别有利于修改的数据结构：链表，但是链表的随机定位能力不行啊，查找的时候动不动就得遍历一遍。如果链表也能像数组一样可以随机定位就好了，这样只需要一个有序链表就可以同时支持O(lgN)查找与O(1)插入删除。通过仔细分析你发现，其实真正需要的也不是完全的像数组那样的完整的随机定位能力，只需要像二分查找那样，第一次能直接跳到链表的中间节点，然后判断目标数据在链表的左半区间还是右半区间，接下来再次跳到链表的那一半区间的中间，反复这样递归比较就好了。哎呀，你就这样发明了二叉搜索树。

这颗二叉搜索树一开始还挺好用的，查找修改都很快，老板满意得不得了。但是用着用着你发现这颗树慢慢地倾斜了，它的左子节点都被你删掉了，而新插入的都是右子节点，我的天呐，这不又退化成链表了么？你深刻反思，觉得在删除的时候不能删完就不管了，插入的时候也不能完事就就走人，你得做一个负责人的人，必须时刻保证二叉搜索树是平衡的。于是你发明了平衡二叉树，你特么真是个天才。

由于你的优秀设计，你的程序跑得很快，客户很满意，老板很满意，你对水涨船高的工资很满意。不过相应的程序的数据量也越来越大了，内存放不下了，这咋办？这可难不倒你，你决定把冷数据持久化到磁盘，内存里只存储热数据，数据结构还是你发明的平衡二叉树。然后你很快发现，由于数据量巨大，平衡二叉树的层数太高了，一次查找可能要遍历到十几甚至几十层的树节点，它们大部分都在磁盘上，这样查找每层的节点都引发一次磁盘IO，这可太慢了。

思来想去，你认为减少树的高度是关健，可是客户数据摆在那里，砍数据量是不现实的，你决定增加树的分叉数，由2叉变成3叉、4叉、5叉树。但好像效果不明显啊，你一咬牙，直接上1000叉树，我艹，几千万的数据，才3～4层的树就搞定了，查找果然快了很多啊，你觉得自己真NB，于是给你的发明起了个名字叫NB树，简称B树(B-Tree)。

一开始你是把数据跟索引节点放到一起的，后来你拍脑袋一想：干嘛不将它们拆开？树内节点只保存索引，而数据全存到叶子节点中，这样有限的内存可以缓存更多的索引节点，查找起来岂不是既快又稳定？而且你发现，因为数据全保存在叶子节点中，如果在叶子页面中加入同级兄弟页的前后引用指针的话，甚至能在范围查找的时候避免跳回到父页。你觉得你发现了一种更NB的数据结构，于是你将它称之为B+树(B+Tree)。

1. B-Tree的真正名称是Balance-Tree，不要被我前面的胡说八道误导了。

2. B-Tree应用在DB中已经发展了很多年，自然衍生了许多优化措施。其中之一就是B+Tree提到的那两点优化，然而这个优化是如此常见，以至于它通常不能与其它B-Tree的变种区分开来。

3. 在很多文献中，人们并不区分B-Tree和B+Tree，而是统称为B-Tree。这有时候会误导那些相对较真的人，也衍生出一些看似严禁实际上没那么重要的问题，我在知乎上搜索到两个相对典型的：《为什么Mongodb索引用B树，而Mysql用B+树?》《为什么 MongoDB 索引选择B树，而 Mysql 选择B+树(精干总结)》。其实不是，人家MongoDB使用的也是B+Tree，只不过在文献里写的是B-Tree