mysql的为什么选取B+树，作为存储结构，与B树的比较？
重点不是背诵 B 树对比表，而是解释页式存储、扇出、树高、范围扫描以及 InnoDB 记录组织。
直接结论
InnoDB 索引采用 B+Tree 结构，是因为它适合按页读写的持久化存储：内部节点主要保存导航键与子页指针，可获得较高扇出和较低树高；叶子层按键有序，便于等值查找、范围扫描和顺序遍历。与把记录也分布在内部节点的典型 B 树描述相比，B+Tree 更利于把导航和数据职责分开，并让范围结果集中在连续叶页。不过“为什么选 B+Tree”还必须结合页大小、缓存命中和具体索引类型说明。
原理与步骤
InnoDB 表空间由页组成，索引页保存有序记录和页之间的层次关系。聚簇索引叶节点保存整行记录，二级索引叶节点保存二级键与主键值；查二级索引若查询列不能被覆盖，通常还需凭主键回到聚簇索引。较大的扇出意味着从根到叶所需页数较少，根和上层页往往容易驻留缓冲池。节点分裂、合并与页填充会影响写放大，因此主键长度和插入顺序也会影响空间与写入成本。
工程场景
例如订单表按主键查询只需沿聚簇索引定位叶记录；按用户和时间的联合二级索引可快速定位某用户的时间区间，并按叶层顺序读取。如果查询只返回索引中已有列，可形成覆盖索引，减少回表。设计时要从真实 where、join、order by 和 select 列出发，用 EXPLAIN 与实际执行统计验证，而不是给每一列建索引。随机且很宽的主键会被复制到二级索引叶节点，可能增加页占用和分裂。
验证与边界
B+Tree 并不保证任何查询都快：低选择性条件、函数包裹、类型转换、错误列顺序或返回大比例数据时，优化器可能选择全表扫描。树高也不是磁盘 I/O 次数的机械等式，因为缓冲池、预读和存储设备会改变成本。官方文档描述的是 InnoDB 物理结构，不能外推到所有数据库引擎。验证要查看索引定义、基数、执行计划、实际行数与缓冲池命中，并在代表性数据量下测量读写代价。
答题练习
- 1页式存储与高扇出
- 2叶层有序支持范围扫描
- 3聚簇和二级索引叶节点内容不同
常见错误
- 只说层数少却不联系页和缓存
- 认为有索引优化器就一定使用
可能追问
- 二级索引为什么可能回表
- 随机主键如何影响写入
来源记录
- 原始来源
- 小林coding
- 来源页面
- 58同城 Java 面试
- 最近收录
- 2026-07-05
- 官方复核
- MySQL 官方文档