- 二叉树：每次只能二选一，找东西要翻太多次，累死。
- 哈希表：瞬间找一个人无敌快，但找“一群连号的人”直接抓瞎。
- B树：目录和内容混在一起，导致目录太厚，找连号也不方便。
- B+树（MySQL用的）：纯薄目录找得快 + 底层连号排好队，单找、群找都无敌！
假设你是档案室管理员，这四种数据结构，就是四种给你安排档案的方式：
1. 二叉树（Binary Tree）—— “只能二选一的瞎忙活”
它的规则是： 每个柜子只有两个抽屉（左和右）。
找档案的过程：
你要找 8000 号学生。
打开第 1 个柜子，上面写着“大于 5000 去右边，小于去左边”。你去了右边找第 2 个柜子。
第 2 个柜子写着“大于 7500 去右边...”。
它的致命缺点：太高、太瘦了！
因为每次只能分成两岔，1万份档案，你要不停地开柜子、关柜子，可能要开 14 个 柜子才能找到目标。
在电脑里，开一次柜子就是读一次硬盘，读14次硬盘，电脑会觉得慢死了。
2. 哈希表（Hash）—— “神奇的任意门，但只能单飞”
它的规则是： 没有任何层级，像一个超级魔术箱。
找档案的过程：
你要找 8 号学生。你对着魔术箱喊一声“8号”， “嗖”的一下，8号档案瞬间就弹出来了。速度天下第一快！
它的致命缺点：无法“一网打尽”。
如果你今天接到的任务是： “把 8 号 到 20 号 的档案全拿出来” 。
魔术箱傻眼了，因为它里面是乱七八糟塞的，根本没排队。你只能对着魔术箱喊“8号”、“9号”、“10号”……连喊 13 次。在数据库里，我们经常需要查“大于xxx小于xxx”的数据，哈希表对这种需求完全是个废物。
3. B树（B-Tree，传统B树）—— “夹带私货的超厚目录”
为了解决二叉树“柜子太多（太高）”的问题，B树改进了：它把一个大柜子做了几百个抽屉，变成了一个又矮又胖的结构。
它的规则是： 它是目录，但目录上直接绑着沉甸甸的真实档案。
找档案的过程：
就像一本书的目录，但奇葩的是，作者把具体的每一页内容，直接贴在了目录对应的标题旁边。
它的致命缺点：
- 目录太占地方了！ 因为目录里夹着厚厚的真实档案，导致一张目录纸写不了几条索引。本来 1 页纸能写 1000 个名字，现在因为夹着档案，1 页纸只能写 10 个名字。结果就是，目录本身变得很厚，你找个名字还是得翻好几页。
- 拿连号档案很累。 如果你要 3号 到 5号 的档案。3号可能在第1个柜子，4号跑到了第3个柜子，你得楼上楼下跑来跑去找，特别折腾。
4. B+树（B+ Tree，MySQL的终极选择）—— “纯粹的目录 + 底层传送带”
MySQL 吸取了上面的所有教训，设计出了最完美的方案。
它的绝招有两步：
第一步：目录绝对纯粹（不夹带私货）。
上面几层全都是纯纯的名字目录，绝对不放厚重的真实档案。这样一来，薄薄的1页纸（一次硬盘读取），就能密密麻麻写下 1000 个名字。找 1 万个人，你最多只需要翻 3 页纸就能找到位置！速度极快！
第二步：所有真实档案都在一楼，且有一条“传送带”连着。
所有的真实档案，全都被赶到了最底层（一楼），并且从 1 号到 10000 号，整整齐齐排好队，而且底下有一条绳子（链表）把它们串在一起。
完美找档案的过程：
老板说：“给我找 10 号 到 50 号 的档案！”
- 你翻开极其轻薄的纯目录，瞬间（只翻 2 3 次）定位到一楼的 10 号档案的位置。
- 拿到 10 号档案后，根本不需要再回去翻目录了！因为底下有绳子连着，你只要顺着绳子往右走，11号、12号……一直走到 50 号。一把抓起来，直接交差！
