数据库索引相关的话题里有一道题几乎每次聊到 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 行树的总层数最多叶子页数按 15 行每页估算可容纳行数2 层1170约 1.75 万3 层1368900约 2053 万4 层约 16 亿约 240 亿看到这里你应该明白为什么面经里偏偏问“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 常见误区踩中一个都扣分我整理了一张表把最常见的几个误区列出来你可以提前对照自检误区问题在哪里正确理解用 log2(2000万) 算出 25 层把 B树 当成了二叉树一个内部页有 1170 个分叉层级是 log1170只背“两千万行三层”没说明前提假设行宽、页大小、页利用率都会改变结论把树高和磁盘 I/O 次数混为一谈忽略了根页在缓冲池中三层树通常只算两次磁盘 I/O以为所有索引结构都一样聚簇索引叶子存整行二级索引只存索引键和主键索引类型不同容量估算也不同不考虑碎片和填充率页不会永远满载随机插入删除后树可能增高一层还有一个细节很多人会忽略如果表上有多个二级索引每个索引都是一棵独立的 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 亿你只要把同一个流程重新走一遍自然就知道该回答四层还是五层。
