MySQL索引选择：B+树的优势与工程实践

1. 数据库索引的底层选择困境

在数据库系统的设计与优化中，索引结构的选择往往决定了系统性能的上限。当我们打开MySQL的源代码，会发现一个有趣的事实：InnoDB存储引擎的核心索引结构既不是教科书上常见的二叉搜索树，也不是更复杂的红黑树，而是选择了B+树这一特定变种。这个选择背后隐藏着怎样的工程权衡？

2000年左右的MySQL开发团队面临着这样的技术决策：当时主流的几种磁盘存储数据结构各有优劣。哈希表虽然查询效率高但范围查询能力差；平衡二叉树在内存中表现优异但面对磁盘I/O时性能急剧下降；B树作为早期磁盘友好型结构已经广泛应用，但仍存在某些场景下的性能瓶颈。最终，B+树以其独特的结构特性胜出，成为MySQL默认存储引擎的基石。

2. B树的核心特性与局限

2.1 B树的基本结构原理

B树（Balance Tree）是一种多路平衡查找树，其设计初衷就是为了解决磁盘存储时的效率问题。一个典型的m阶B树具有以下特征：

• 每个节点最多包含m个子节点
• 除根节点和叶子节点外，每个节点至少有⌈m/2⌉个子节点
• 所有叶子节点都位于同一层
• 节点中的关键字按升序排列，对应子树的关键字范围划分

以3阶B树为例，每个非叶子节点可以存储1-2个关键字，拥有2-3个子节点。当插入新数据导致节点关键字超过上限时，会发生节点分裂操作，保持树的平衡性。

2.2 B树的存储效率分析

B树将相关数据尽量存储在相邻的磁盘块中，通过减少磁盘I/O次数来提高性能。例如在一个高度为3的B树中：

• 根节点常驻内存
• 第二层最多需要1次磁盘读取
• 第三层最多需要1次磁盘读取
• 因此最坏情况下只需2次磁盘访问即可找到目标数据

但B树的这种设计也带来了明显的空间浪费。每个节点既存储键值也存储实际数据，当数据记录较大时，单个磁盘块能存储的键值数量会显著减少，导致树的高度增加。

2.3 B树的查询性能瓶颈

虽然B树的等值查询效率很高，但在处理范围查询时存在明显缺陷。例如执行SELECT * FROM table WHERE id BETWEEN 100 AND 200这样的查询时：

1. 需要先定位到100所在的叶子节点
2. 然后沿着链表向后遍历直到200
3. 但由于B树的叶子节点之间没有直接链接，每次访问相邻节点都需要回溯到父节点