MySQL为什么用B+树做索引存储结构？

嘿，你在说什么？刚开始接触数据库的时候，我也对B+树感到困惑。
但后来我努力了，逐渐意识到为什么它是MySQL的首选。

你看，当时我负责的是一个数据量很小的系统，只有几十万条。
但每当我检查某些东西，尤其是范围检查时，它总是很慢。
后来我们改用B+树索引，嘿嘿，速度立马提升了。
这是 B+ 树最好的部分——I/O 节省。

为什么要节省 I/O？想想看，硬盘驱动器以块读取数据，而不是字节。
B+树的设计目的是在非叶子节点上存储键而不存储数据，并且节点大小与硬盘的块大小类似，例如1 6 KB。
这样，每次读取时，您可以一次读取整个节点，而不必重复读取和停止。
如果使用二叉树，树将非常深，并且查询可能必须被读取很多很多次。

此外，B+树的叶子节点仍然是通过链表连接的。
我曾经有一个项目，需要在一定的时间间隔内检查订单。
我使用B+树直接找到开始时的叶子节点并沿着链表读取。
多么平静啊。
如果使用B树，读取中途可能要回去找其他节点，非常繁琐。

而且，B+树节点可以存储很多子节点，而且树的深度也不是那么深。
我计算过，假设一个节点存储1 00个键，那么三层B+树可以覆盖一百万条数据。
如果你想一想，如果树的层数减少了，问题的数量就会减少。

相比那些二叉树、AVL树、红黑树，层数更多，I/O的数量就像打砖块一样。
B树虽然没有那么好，但是没有叶子的节点存储数据，节点容量小，树有点深，范围控制很麻烦。

哦，对了，B+树的另一个优点是索引键可以出现在树中的多个地方，作为冗余索引，这样可以加快查询速度。
我有一个使用 LOAD DATA INFILE 将数据添加到数组的客户端。
他表示，使用B+树索引会让导入速度快很多。

所以，MySQL使用B+树是因为它的设计，特别适合硬盘这样的慢速设备，节省I/O，并且可以快速查询范围数据。
其他树木要么控制缓慢，要么维护成本很高。
B+树怎么这么有用呢？
但是现在出现了一些新的东西，比如哈希索引，在某些场景下比B+树更快。
但在较旧的场景中，尤其是需要检查大量数据的场景中，B+树仍然像老狗一样耐用。

mysql多级查询

此 SQL 检查菜单层次关系。
说白了，就是找父子级别。

菜单表采用a.id（子ID）和a.father_id（父ID）。
那么左侧连接菜单表示为b，条件为a.id=b.father_id。

结果列是a.id、a.father_id、b.id（父表的ID）。

我上周刚刚处理了类似的请求。
您确定需要 b.id 吗？