2-001：为什么 MySQL 选择使用 B+ 树作为索引结构？
MySQL 选择 B+ 树（B+Tree） 作为索引结构的主要原因如下：
1. B+ 树的结构特点
- 多路平衡树
- B+ 树是 一种平衡的多叉树（相比二叉树，分支因子更高，层级更少）。
- 所有叶子节点等高，即数据存储在叶子节点，保证查询的稳定性。
- 非叶子节点仅存储索引（键值），不存储数据
- 这意味着 一个节点可以存储更多的索引值，相较于 B-Tree（B 树），单次磁盘 I/O 可读取更多的索引，提高查询效率。
- 叶子节点之间有双向链表
- 支持 范围查询（range search），而 B-Tree 需要进行中序遍历才能完成范围查找。
2. B+ 树对磁盘 I/O 友好
数据库的索引一般存储在磁盘上，而磁盘的读写速度远低于内存。B+ 树减少了磁盘 I/O 次数，提升了查询效率：
-
减少磁盘 I/O 层级
-
假设每个索引节点大小为 4KB
，每个节点存储 100 个索引键，则：
- 3 层的 B+ 树 可索引 百万级数据；
- 4 层的 B+ 树 可索引 十亿级数据。
-
这意味着查询一个索引键通常只需要 3~4 次磁盘 I/O。
-
-
索引节点加载进内存
- MySQL 一般会将 B+ 树的根节点和部分内部节点 缓存进内存，使得查询更快。
3. B+ 树支持范围查询
- B-Tree 需要中序遍历整个树才能完成范围查询，效率较低。
- B+ 树的叶子节点通过链表连接，只需要在叶子节点中顺序扫描即可，高效完成范围查询。
4. B+ 树比 B-Tree 更适合数据库索引
| 特性 | B-Tree | B+Tree |
|---|---|---|
| 数据存储 | 每个节点存数据 | 仅叶子节点存数据 |
| 索引大小 | 索引和数据混存，索引容量小 | 仅存索引，单节点可存更多索引值 |
| 查询效率 | 可能遍历多个节点 | 叶子节点有链表，范围查询快 |
| 磁盘 I/O | 需要更多 I/O | I/O 次数更少 |
| 范围查询 | 效率低 | 直接遍历叶子节点链表，高效 |
5. 为什么不选择 Hash 索引？
MySQL 默认使用 B+ 树，而不是哈希索引（Hash Index），主要有以下原因：
- 哈希索引不支持范围查询
- 例如
SELECT * FROM users WHERE id BETWEEN 10 AND 50; - Hash 索引需要计算哈希值，而哈希值的存储是无序的，无法进行范围扫描。
- 例如
- 哈希索引不支持模糊查询（LIKE）和排序（ORDER BY）
LIKE '%abc%'在 B+ 树中可以走索引，但 Hash 索引无法利用索引。
- 哈希索引存在哈希冲突
- 发生冲突时，多个值映射到同一哈希桶，会导致 查询退化为链表遍历，影响查询效率。
6. 为什么不使用跳表（SkipList）？
跳表（SkipList）在 Redis 中使用，但在 MySQL 中未采用，原因如下：
- 跳表的索引层级较少，查询时间复杂度为 O(log n)，与 B+ 树相同。
- 跳表的存储空间比 B+ 树大，因为需要维护多个指针，导致缓存命中率下降。
- B+ 树的磁盘访问更高效，每次读取一个磁盘页，而跳表由于链式存储，可能会导致更多随机访问。
7. 总结
- B+ 树减少磁盘 I/O，查询效率高，适合 大规模数据查询。
- 支持范围查询和排序，相比 Hash 索引，适用场景更广。
- 叶子节点采用链表结构，支持顺序遍历，提高范围查询效率。
- 相较于 B-Tree，B+ 树索引层级更少，查询速度更快。
- 相比 Hash 索引，B+ 树不受哈希冲突影响，支持模糊查询、范围查询和排序。
因此，MySQL 选择 B+ 树作为索引结构，是综合性能最优的方案！ 🚀
8. 概括图：
如图：
