正文链接：mp.weixin.qq.com/s/krJ7vXnNH… 转载自yes的练级攻略公众号 所有图片都来自群聊
一个很好的博主当然要有爱妃啊，而我就是其中一个，但是最近博主竟然荒废了，我们这些爱妃那可不得看看博主最近在忙什么，下面就进入正题： 这篇文章的故事情节很好推荐这篇文章也是因为小Y【下文的主角】已经被打击了，可能这个MySQL帝国会被停滞不前，种种原因都指向小Y 小Y在为建设MySQL帝国而努力中,如图：
过着不节制的生活
无情吹捧
招募爱妃
去不一样的球馆放松 没有插入视频的地方，不然也可以看小Y怎么放松的方法
加大力度建设MySQL帝国中
就说大实话的老实人不去建设MySQL帝国
编译代码在线摸鱼，不考虑MySQL帝国的建设
群友都看穿了，只是稍微暗示
群友竟然表白了这个不专心建设帝国的难人，争相吃醋
竟然怀疑群友不是他的爱妃
放假写文，但是竟然不是去建设MySQL帝国，
亲切的问候爱妃们，然后想放毒[朋友圈只开放三天之内的没有图了]
成功的再次偏离MySQL帝国的轨道
再次
再次荒淫无度
秀完装老实人
错怪了小Y，放假稍微想建设MySQL帝国,但是小Y已经被打击到了
小Y被打击到了
进入正题：小Y为创建MySQL帝国的努力 为什么是小M看到小Y的get点应该知道小M是谁了吧 我是小M，我在卡拉巴拉星球。 我喜欢数据，我立志成为一个数据管理者。 所以我来 Y 公司应聘，听说他们的数据量挺大的。 面试过程还是挺简单的。 我用 007 这三个数字就轻易打败了一堆吹嘘 996 的应聘者。 此刻，我独领风骚。
1
今天是我第一天上班，我笔直地坐在工位上，等着老板的宠幸。 下午两点。 Y 老板推门而入，打着哈欠看着我：“007，你背有问题？坐得这么直？” “老板你好，我叫小M，不是叫 007 ，007 是我对公司的热爱，是我的毕生....” “打住打住，看到你前面办公桌上十几条数据了么？” “你的任务就是管理好它们，这些数据随时会增加、查阅、删除、更新的哦。” 我激动着、颤抖着回答：“Yes，Sir！”
2
花了10分钟的时间，我把桌上的数据都扫视了一遍。 是的，没错，就十几条数据我花了十分钟。 因为这是我的第一份工作，我热爱！ 这些数据都来自一个叫 User 的部门，它们都有一样的结构：
这堆数据的 ID 都是有规律的，我想着就按顺序把它排排坐，我用链表将它们相连。
每次查找数据，我从头开始遍历往后找就行了，有序，简单。 我真是个小天才。 就这样日复一日，年复一年，User 的数据在不断的增加，现在已经多达百条了。
这个链表也越来越长，每次老板来找我要数据，我查找的时间也越来越慢。 而且不仅是大老板，我发现好多小老板也来找我要数据。 我快要累死了，我的腰渐渐地也直不起来了。
3
5月1号深夜，今天是劳动节。 我依旧在公司加班。 我想不能再这样下去了，是时候祭出我的秘密武器了！ 只有在夜深人静一个人的时候，我才能召唤它！ 螺蛳粉！
没错，就是它！ 因为我发现，嗦了螺蛳粉之后，我的脑子特别清晰，思维特别地发散。 为此，我还特意去医院检查了下脑子，医生说从片子上看的话一切正常，不过从感觉上看我可能不太正常。 不管了，反正我知道，螺蛳粉确实能赋予我通透的头脑。 因为，此时我的脑子已经开始动起来了！ 有了！ 我忽然回想起，在大学里面有一门叫《数据结构》的课程里讲了二分法。 现在有近一千条有序的数据，我把它按每十条数据分为一组，于是我吭哧吭哧的一顿操作。
(为了美观，就画10组)然后我再为每一组都配置一个槽，每个槽记录了每组最大的那条记录的地址。
这样，我就可以通过二分法快速查找记录啦！ 假设现在就10组数据，然后我要找 ID 等于 12 这条数据，我就：
- 先计算中间槽的位置
(1+10)/2=5，通过地址找到第五组，此时第五组ID是50，12<50，所以继续二分。 (1+5)/2=3，通过地址找到第三组，此时第三组ID是30，12<30，所以继续二分。(1+3)/2=2，通过地址找到第二组，此时第二组ID是20，12<20，所以继续二分。(1+2)/2=1，通过地址找到第一组，此时第一组ID是10，12>10，现在能断定12在第二组。- 从图中看起来第一组和第二组是分开的？实际上地址是相连的，所以通过第一组最后一条数据，可以往后随着单向链表遍历，找到ID为12的这条数据。
是不是很方便？ 总结的来说：
- 先通过二分法找到数据所在的槽。
- 然后再通过单向链表遍历得到数据。
在数据量很大的时候这种查找方式非常快速！ 因为查找数据的时间复杂度从O(n)几乎简化成了O(lgn）！ 我称之为页目录，我可真是个小天才呢！
4
就这样，日复一日，年复一年。 User 的数据量还在逐日增加。 我发现每次查询都需要掏出全部的名单来找。 我这小胳膊细腿的，都快抬不动了。 于是，在一个月黑风高的夜晚，我又掏出了螺蛳粉。 灵光乍现！
我以一千个数据为一个界限来分割数据，我将每一千个数据称之为页。 没错，我又想出了 idea，我将所有数据分为一页一页，每页之间用双向链表相连。
这样每次查询，我就不需要一次把有所数据都拉出来，我可以一页一页翻阅过去。 当然，页内部还是按照刚才那样分组访问。 现在我是这样查找数据的：
- 每次查数据我从第一页开始找。
- 然后按照页内查找的方式二分去查数据，找不到就通过链表访问下一页。
因此，访问速度并没有变快，只是每次不需要把数据全部捞出来，只要一页一页的捞。 我的胳膊得到了解放。
5
公司越来越大，User 的数据爆炸性增长。 分的页也越来越多，老板和小老板们开始抱怨了。 老板说，“我让你找个人，你找了1小时？你今年年终奖还想不想要了！” “唉，那个人在最后一页，我翻的要死才翻到，我太难了！” 虽说在心里抱怨，但是我知道这样下去不是办法。 头可断血可流，年终奖不可少！ 别问，问就是螺蛳粉！ 果不其然，螺蛳粉是无敌的。 解决法子有了！ 每个页都标上独一无二的页号。 参考书本目录的设计，我还专门搞了一个页，页里面的存储就是目录！ 我称它为目录页。
你看，这样我就能通过这个目录页找到对应的数据页。 比如：我现在要找 ID 为 500 的那条数据。
- 我遍历目录页数据就可以知道该条数据在页1。
- 然后就开始在页内通过老套路二分来查找数据！
可能有人觉得，目录页也是有大小的呀！装不下怎么办？ 没事，和数据页一样，新增页呗！
可能有人会问，那目录页多了，查找目录页也会变慢的呀！ 你说的没错，但这可难不倒我这个小聪明！ 我们可以再搞一级目录，我称之为目中目(开个玩笑~)！
这样，每次我从根目录开始查询，只要几次查询我就能找到想要的数据！ 我称这整一个为索引！
Y 老板看到了我的设计之后，拍了拍我的脑袋，“007，有一手啊，我看你这结构看着像一棵树，我这个人又喜欢吹牛 B，你看这玩意叫 B 树怎么样？” “不行老板，我觉得这 B 格不够高，要么叫B+树吧？” “行啊，007，年终奖我提前发给你！” “叮铃，支付宝到账，0.1元。” 我：“...........” “对了 007 ，这 User ID 太不好记了，下次我打算只告诉你名字，让你找。” 我内心：“@#%^&%........” 故事未完，敬请期待 ~
哈哈，第一次写这类故事，有点意思。 这篇主要写的是关于MySQL InnoDB 聚簇索引的设计，阐述了 MySQL 的数据到底是如何查找的。 我记得之前阿里的面试官就问过我这个问题，让我说说数据在索引上是如何找到的，越细越好。 嘿嘿，这下知道了吧。 不过，由于故事的原因，有些描述都是不准确的，比如上面说的什么每一千条数据分为一页。 我下面统一更正一下并补充一些点，看好了啊！
- MySQL 一页默认16 KB，所以不是按数量的，是按总的记录数所占的空间。
- 页内记录是单向链表连接，页之间是双向链表连接。
- 当一页数据存满了之后需要进行页分裂，也就是拆分下记录变成两个页。
- 页分裂操作也可能导致多个页都满了，比如你往一个页中间插入数据，挤出一条数据到下一页，然后下一页也满了，发生级联，影响性能，所以建议主键有序，这样不会往中间的页插入数据。
- MySQL页内默认会有一条最大记录和一条最小记录不存储数据，就是这样设计的，和链表dummy节点类似。
- 一页除了存储数据还有一些元数据，比如FileHeader、PageHeader等等，太细了讲了你现在记得住，过两星期也记不住，我也一样。
- 一条记录也有很多细节。
像大部分人可能知道 InnoDB B+树索引的设计。 也能说出为什么要用 B+ 树，但是很少会说到页内的二分查找。 其实这样的设计很常见，像 Kafka 的索引也采用了二分，一般数据量大了，数据有序的情况都会上二分。 下次面试官问你，你就把这个跟他说说，面试官会觉得，啧啧真细啊。 对了，我上述讲的只是索引结构大致布局，想要看详细的可以看《从根儿上理解 MySQL》，比如 FileHeader 有什么字段啊啥的。 不过，我个人觉得没必要这么细，反正记不住，精髓掌握的即可。 如果你喜欢这样故事类的文章，可以留言让我知道，我之后多往这方面写。
