mysql索引为啥用B+树，不用二叉树或者B树
数据库面试 + 工程设计的经典问题，本质不是“B+树有多厉害”，而是：磁盘 I/O、局部性和 CPU 缓存友好性共同决定了 B+树是最优解。
我会按「从直觉 → 到磁盘 → 到数据库真实场景」的顺序讲清楚，最后给你一个对比表，方便你记忆和面试。
一、先给结论（面试一句话版）
MySQL InnoDB 使用 B+树，是因为：树矮（减少磁盘 I/O）、数据全在叶子节点（范围查询快）、叶子节点成双向链表（扫表快）、非叶子节点只存 key（单页能放更多索引，进一步降低树高）。
二叉树 / AVL / 红黑树太高，B 树范围查询和扫表效率低，只有 B+树在磁盘场景下全面胜出。
二、为什么二叉树 / 红黑树不行？
1. 二叉树的最大问题：树太高
假设你有100 万行数据：
结构 | 大概高度 |
|---|---|
二叉查找树 | ~20 |
平衡二叉树（AVL） | ~20 |
B+树（InnoDB） | 3~4 |
问题来了：
MySQL 的数据在磁盘上
每次比较一个节点 =一次磁盘 I/O<