2000万行B+树高度怎么算？InnoDB三层推导全解析

数据库索引相关的话题里，有一道题几乎每次聊到 B+树 都会被翻出来：一张表存了 2000 万行，主键是 BIGINT，使用 InnoDB 存储引擎，这棵 B+树 的高度到底是多少，怎么算？我刚看到这个面经标题时也愣了一下，因为问法太像一个只需要背结论的“八股题”，但真正到面试现场，你会发现面试官在乎的从来不是“三层”两个字，而是你能不能把三层推导出来。

这篇文章不是让你背数字，而是把这套估算方法彻底讲透。对准备面试的后端开发来说，它是一道高频送分题；对已经写业务、但对索引结构只有一个模糊印象的人来说，它也能帮你把“为什么索引能这么快”这件事落到具体的页、指针和行大小上。

1. 为什么这道“算树高”的题会反复出现

1.1 面试官到底想听你说出什么

先想一个问题：如果面试官只是想考知识点，直接问“B+树 为什么快”就够了，何必专门问“2000 万行有多高”？答案在于，这个数字特别适合用来观察一个人的工程直觉。

2000 万行是一个很常见的中型业务表量级，出现在各种订单、流水、用户信息场景里。它既不是小到没感觉，也不是大到需要直接说分库分表。面试官拿着这个量级问你索引高度，其实是想确认三件事：知不知道 B+树 每层能分出多少个叉，也就是扇出；能不能把行数转换成页数；能不能用估算结果解释现实中的查询延迟来自哪里。

如果你直接回答“三层”，这个答案本身没有错，但它没有信息量。真正好的回答应该从页大小、主键大小、指针大小一步步算给面试官看。哪怕你只把公式写出来，结果算成三层还是四层，都比硬背一个结论更有价值。

1.2 它背后是同一类容量估算问题

这道题其实不是一道孤立的记忆题，它是一整类容量估算问题的代表。你只要掌握了“树高由扇出和叶子容量决定”这个思路，以后面试官把 2000 万换成 2 亿，或者把主键从 BIGINT 换成 INT，甚至问你二级索引为什么有时候需要回表，你都能用同一套公式往下推。

类比一下：B+树 的每一层就像一个文件柜的目录区，目录区里不放大文件，只放“标签”，标签上写子文件柜编号。文件柜能叠多少层，取决于两层目录之间能挂多少个标签，以及最底下每个柜子能塞多少份文件。树的高度不是拍脑袋出来的，是由这两个数排队算出来的。

2. 动手算之前，四个参数先确认清楚

2.1 页大小、主键、指针和行大小

要算任何一棵 B+树 的高度，第一步不是套公式，而是把所有假设摆到桌面上。默认情况下 InnoDB 的页大小是 16KB，也就是 16384 字节。这个值可以用下面这条 SQL 在真实的实例里确认：

SHOW VARIABLES LIKE 'innodb_page_size';

生产环境里绝大多数实例都是 16KB，所以这道面经题里的“默认”基本成立。接下来是主键大小，BIGINT 占 8 个字节。如果在字段定义上用的是 INT 或 BIGINT 的 unsigned，只是取值范围不同，存储大小不会因为 unsigned 而改变。

第三个参数是内部节点里“指向子页的指针”所占的字节数。InnoDB 内部页中存放的内容是“主键值 + 子页页号”，这个结构会带着一些记录头信息，面试里按 6 个字节估算是很常见的做法。于是内部节点里每一个索引项大约占 8 + 6 = 14 字节。

第四个参数是叶子页能存多少行。这里有个关键前提：聚簇索引的叶子节点存的是整行数据，不是只存在索引键。但面经题目没有给表结构，我更倾向于先声明“我按平均行大小 1KB 来估”。1KB 不是一个随便拍的数字，它对应着大多数业务表几列到十几列字段时的行宽，既有代表性，又方便口算。如果你觉得真实表行宽只有 200 字节，那就改用 200 字节去算，公式完全一样。

2.2 扇出是怎么算出来的

把前三参数放在一起，内部节点的扇出就出来了：

16384 ÷ 14 ≈ 1170

也就是说，一个内部页大约能放下 1170 个索引项，每个索引项指向一个下层页面。这个 1170 就是这棵 B+树 的分叉数。1170 这个数字不算特别精确，因为内部页同样有页头、页目录、预留空间，但用它做面试估算完全没有问题。

为什么 B+树 要把内部节点做得这么“瘦”？二叉树的每个节点最多两个分叉，2000 万行要大概 25 层；而 B+树 一个节点就有 1170 个分叉，高度瞬间压到三层左右。内部节点不存数据只存指针，目的就是尽量提高这个分叉数。你可以这样理解：去写字楼找某家公司，大厅的楼层索引只写公司名和楼层号，不把每家公司的员工名单都贴在大厅里，这样索引牌才能挂得下足够多的公司。

3. 2000 万行三层推导全过程

3.1 叶子层需要多少页面

现在开始算最底下那一层。假设平均一行 1KB，一个 16KB 的叶子页理论上能放：

16384 ÷ 1024 ≈ 16 行

但这 16 行是理论极限，页里还有行格式、页目录、碎片空间。落到真实表上，做了批量插入但从来没有整理过的叶子页，利用率可能只有 70% 到 90%。面试时不用把这些细节全列出来，你只要说“按 15 到 16 行一张叶子页估算”就已经足够严谨。

按每页 15 行来算，2000 万行需要多少张叶子页：

20000000 ÷ 15 ≈ 133.3 万

所以叶子层大约需要 133.3 万个页面。这个数字也可以直接换算成存储量：133.3 万页乘以 16KB，约等于 21GB。2000 万行数据占用 20 多个 GB，在中型业务库里是很正常的事情。

3.2 再来把中间层“叠”上去

底层页面数算出来以后，中间层就只是一个除法问题。根节点的下一层每个页面可以指向 1170 个叶子页，所以中间层页面数大约是：

1333000 ÷ 1170 ≈ 1139

这个数字仍然大于 1，说明叶子页不能全被根节点直接指向，中间需要一层内部页。再往上，根节点只需要一层就够了吗？看根节点的扇出能不能覆盖 1139 个中间页。1139 小于 1170，所以根节点一个页面就能把所有中间页全部挂在自己下面。

这样整棵树的结构就是：最底下 133.3 万个叶子页，中间一层 1139 个内部页，最上面一个根页。从根到叶子，一共三层。

下面这张表可以更直观地展示不同层级能容纳多少行，假设每页 15 行：

看到这里你应该明白为什么面经里偏偏问“2000 万行”了：在三层 B+树 的容量边界附近，三层大约能放 2053 万行，2000 万正好压线放得下。如果行宽再大一点，或者页利用率低一点，可能就需要四层。这也是为什么这道题值得问，因为结论不完全固定。

3.3 树高和磁盘 I/O 次数要分开说

很多文章会把“树高三层”直接说成“查询要三次磁盘 I/O”，这个说法需要打个问号。三层 B+树 从根到叶子要经过三个节点，但真实查询时根节点大概率已经缓存在 InnoDB 的缓冲池里了。缓存池就是数据库在内存里划出来的一片区域，经常被访问的页会留在里面，根页永远是最热的那一个。

所以更准确的说法是：如果根页在内存中，一次主键等值查询只需要读一次中间页和一次叶子页，也就是两次磁盘 I/O；如果连根页都没有被缓存，那才是三次。面经里说“三层树，两次随机 I/O”，也是基于这个假设。

你可以把这一层说出来，会让面试官觉得你不只背了结构，还理解了缓存模型。单看这一段不算什么本事，但能把树高和 I/O 次数分开讨论的人，确实不多。

4. 常被追问的变体题，提前准备

4.1 主键从 BIGINT 换成 INT 会怎样

如果主键从 BIGINT 的 8 字节变成 INT 的 4 字节，内部节点的索引项就从 8 + 6 = 14 字节变成 4 + 6 = 10 字节，扇出变成：

16384 ÷ 10 ≈ 1638

扇出从 1170 提高到 1638，大约提升了四成。如果叶子页仍然按每页 15 行估算，三层能容纳的行数会变成：

1638 × 1638 × 15 ≈ 4023 万

只把主键缩窄 4 字节，三层容量从 2053 万跳到 4000 万以上。这个变体题很容易出现在追问环节，面试官想看的不是你会不会算，而是你有没有意识到“主键长度直接影响扇出”。所以生产环境中，如果不是特别讲究可扩展性，INT 主键确实比 BIGINT 更省空间，尤其在大量二级索引存在时会放大这个收益。

4.2 如果是二级索引，结果还一样吗

聚簇索引的叶子页存整行，二级索引的叶子页只存“索引列 + 主键”。比如有一个 VARCHAR(32) 的索引列和 BIGINT 主键，一个二级索引的叶子项大约 40 字节，一个叶子页能放：

16384 ÷ 40 ≈ 409 项

2000 万行对应的二级索引叶子页大约是：

20000000 ÷ 409 ≈ 4.9 万页

再用扇出 1170 往上推，中间层约 42 页，根一层覆盖，所以它仍然是三层。二级索引的叶子项比聚簇索引的整行更短，所以往往也能保持很高的扇出。

但这里有个重要的附加代价：二级索引不是覆盖索引时，需要根据叶子页里存的主键回到聚簇索引再查一次整行，这个过程叫回表。回表等于额外执行一次聚簇索引的 B+树 查询，树高两层的话就是多次随机 I/O。所以“二级索引看起来更瘦”不等于“查询更快”，还要看能不能用覆盖索引把回表省掉。

4.3 页大小、填充率和碎片怎么影响结果

InnoDB 的页大小在实例初始化时固定，默认 16KB，但在某些版本下也支持 8KB、32KB、64KB 等配置。页变大以后，同层的扇出和叶子页容量都会变大，树会更矮；但读取一个页的成本也变高，随机 I/O 一次带回来的数据更多，可能造成浪费。这就是为什么页大小不是越大越好，而是一个权衡。

填充率是最容易被忽略的因素。如果一张表经常随机插入删除，页会有分裂和碎片，实际有效使用率可能只有 70% 左右。原本每页 15 行，打了七折就变成每页 10 行，2000 万行需要 200 万张叶子页，三层已经放不下了，就要升到四层。

所以“2000 万行一定三层”这句话并不严谨。更准确的说法是：在常见业务行宽、默认 16KB 页、页利用率不算差的情况下，2000 万行的聚簇索引是三层。如果你脱口而出“必然三层”，遇到一个较真的面试官，很容易被碎片率这种追问堵住。

5. 回答这道题的表达方式与常见坑

5.1 一套直接可用的回答模板

面试的时候不要上来就说结论，先表明假设，再一步一步算。我给你一个可以直接套用的表达：

“我按默认情况来估：16KB 页、BIGINT 主键、InnoDB 聚簇索引。内部节点每个索引项约是 8 字节主键加 6 字节子页指针，一共 14 字节，所以扇出大概是 1170。平均行宽我按 1KB 估，一个叶子页理论 16 行，考虑页内开销按 15 行算。2000 万行需要大概 133 万张叶子页，除以扇出得到中间层 1139 页，再除以扇出小于 1，所以总层数是三层。如果行宽很大，或者页利用率很低，三层可能放不下，会到四层。”

这套回答的最大优点是，它把假设、公式、计算、边界条件全部说完了。面试官听完之后如果要追问，也只会顺着你的参数继续问，比如“如果主键改 INT 呢”或者“如果平均行 2KB 呢”，你马上就能接上。

5.2 常见误区，踩中一个都扣分

我整理了一张表，把最常见的几个误区列出来，你可以提前对照自检：

还有一个细节很多人会忽略：如果表上有多个二级索引，每个索引都是一棵独立的 B+树。聚簇索引是三层，不代表所有二级索引必然三层。索引列如果特别长，比如几个 VARCHAR 字段拼在一起，二级索引叶子项可能很大，容量和层数都要重新算。

6. 后续扩展：如何在真实环境验证和化用

6.1 用系统变量和表状态做粗略体检

真实工程里，你可以用数据库自己的统计信息来验证这套估算。比如先看页大小：

SHOW VARIABLES LIKE 'innodb_page_size';

再看一张表的整体存储情况：

SHOW TABLE STATUS LIKE 'test_table'\G

返回结果里的Data_length字段，基本可以理解为聚簇索引占用的总字节数。把它除以页大小，就能得到这张表聚簇索引的总页数。比如Data_length是 21GB，页大小 16KB，总页数大约是 134 万页。前面算过 2000 万行、三层树的总页数大约也是这个数量级，两者可以互相印证。

注意这只是一个粗估，因为Data_length包含了叶子页和所有非叶页，而且碎片、前缀压缩都会让它有些偏差。但它足够帮你判断一张表是不是处于正常体量，以及索引高度是不是真的会到四层。

6.2 从树高联想到缓存和写入成本

树高本身不是终点，它直接关联到缓存效率和写入成本。以 2000 万行三层树为例，中间层大约 1139 页，加上根页，非叶层约占 1140 页，也就是 18MB 左右。这个体量放进 InnoDB 缓冲池里没有任何压力，几乎可以常驻内存。

所以你会看到，主键等值查询的绝大部分成本，其实落在最后那一次叶子页随机 I/O 上，而不是中间层的遍历。这也是“单行查询再快也就快到这里”的原因。反过来，如果表因为索引设计不当出现页分裂，或者写入放大严重，每次插入都要同时改动多个索引页，延迟就会明显上升。

我在实际项目里经常把这些估算用来评估一件事：一张表如果再增加一个二级索引，占用多少空间，插入速度会恶化多少，查询能不能靠覆盖索引省下回表。先算扇出，再算叶子页数，最后乘上页大小，基本上十分钟就能给出版本结论。比直接凭感觉说“索引太多不好”要有说服力得多。

这道题看着像八股，但只要你把“页大小除以索引项大小得到扇出，行数除以每页行数得到叶子页数，再除两次扇出看是否接近一页”这套思路记住，它就不再是一个需要背的答案，而是一个能复用的计算工具。下次面试官把 2000 万换成 2 亿，你只要把同一个流程重新走一遍，自然就知道该回答四层还是五层。