这是一个非常经典且常被问到的 MySQL 面试题。要计算 MySQL 三层 B 树能存多少数据我们需要拆解 B 树的结构、页Page的大小、索引项的大小以及数据行的平均大小。结论先行在默认配置下页大小 16KB主键为 BIGINT单行数据约 1KB三层 B 树大约能存储 2000 万 ~ 2000 万 行数据。第一层根节点约 16 个指针。第二层中间层约 16 × 1170 ≈ 1.8 万个指针。第三层叶子节点约 1.8 万 × 1170 ≈2100 万行数据。1. 核心参数假设为了进行估算我们需要设定一些标准参数基于 MySQL InnoDB 默认配置页大小 (Page Size)16KB(16384 字节)。这是 InnoDB 存储数据的最小单位。主键类型BIGINT(8 字节)。这是最常见的场景。如果是INT(4 字节)容量会更大。非主键索引指针在 B 树内部节点中指针通常指向页占用6 字节。单行数据大小假设平均为1KB(1024 字节)。这包括主键、几个常用字段和开销。如果行数据很大如包含大文本叶子节点能存的行数会减少但树的高度可能不变因为内部节点只存索引。B 树结构非叶子节点 (Non-Leaf)只存索引键值Key和指针Pointer。叶子节点 (Leaf)存索引键值Key和实际数据Data。2. 逐层计算过程第一层根节点 (Root Node)根节点也是一个页16KB。它不存数据只存索引键和指向第二层节点的指针。一个索引项的大小 主键值 (8 字节) 指针 (6 字节) 14 字节。根节点能存的索引项数量 页大小 / 索引项大小16384÷14≈1170 16384 \div 14 \approx 117016384÷14≈1170注意这里有一个常见的误区。根节点通常比较特殊它可能存不下 1170 个因为页头有开销。但在估算时我们通常认为根节点能存1170个指针指向第二层。修正实际上根节点存的是(Key, Pointer)对。如果主键是 8 字节指针 6 字节那么16384/14≈117016384 / 14 \approx 117016384/14≈1170。结论根节点有1170个指针指向第二层的 1170 个节点。第二层中间节点 (Intermediate Nodes)第二层有 1170 个节点每个节点也是一个 16KB 的页。每个中间节点的结构与根节点类似只存(Key, Pointer)。每个节点能存的指针数同样约为1170个。第二层总指针数即指向第三层叶子节点的指针总数1170(根节点指针数)×1170(每个中间节点的指针数)1,368,900 1170 (\text{根节点指针数}) \times 1170 (\text{每个中间节点的指针数}) 1,368,9001170(根节点指针数)×1170(每个中间节点的指针数)1,368,900结论第二层共有约136.9 万个指针指向第三层的 136.9 万个叶子节点。第三层叶子节点 (Leaf Nodes)第三层是叶子节点这里存储实际的数据行。每个叶子节点的大小16KB。每个叶子节点能存多少行数据假设每行数据大小为1KB(1024 字节)。叶子节点中还需要存储主键8 字节和指向下一行的指针9 字节InnoDB 叶子节点有双向链表指针以及页头开销约 100 字节。有效数据空间 ≈16384−100(开销)≈1628416384 - 100 (\text{开销}) \approx 1628416384−100(开销)≈16284字节。每页行数16284÷1024≈15.916284 \div 1024 \approx 15.916284÷1024≈15.9。为了计算方便通常估算为16 行或者更保守一点10-15 行。更精确的估算如果行数据较小如 500 字节每页能存 30 多行如果行数据较大2KB每页只能存 7-8 行。我们取一个中间值每页存 1000 字节约 16 行。(实际上 InnoDB 的页内记录有变长字段和偏移量通常每页能存100-200行小数据或者10-20行大数据。这里假设平均1KB/行则每页约16行不对16KB / 1KB 16 行。这个估算偏小因为通常行数据不会正好 1KB 且包含很多开销。让我们重新调整一下常见的经验值)。修正估算经验值在 MySQL 社区和官方文档的估算中通常假设如果主键是BIGINT非主键索引是VARCHAR等。每页16KB大约能存100 行左右假设行平均 100-150 字节不通常行是几百字节到 1KB。让我们用更严谨的数学假设行大小 1KB。每页行数 16384/10241616384 / 1024 1616384/102416行。总行数 1,368,900×16≈21,902,4001,368,900 \times 16 \approx 21,902,4001,368,900×16≈21,902,400(约 2200 万)。如果行大小 500 字节。每页行数 16384/500≈3216384 / 500 \approx 3216384/500≈32行。总行数 1,368,900×32≈43,804,8001,368,900 \times 32 \approx 43,804,8001,368,900×32≈43,804,800(约 4400 万)。通常的面试标准答案假设每页存100行这是一个比较保守且常见的估算考虑到行开销、变长字段等或者假设每页存16行如果行很大。让我们采用最经典的估算逻辑Percona/MySQL 官方常见说法根节点1170 个指针。中间层1170 个节点每个 1170 个指针 -11702≈1361170^2 \approx 13611702≈136万指针。叶子层136 万个节点。每个叶子节点存多少行如果行数据是 1KB每页存 16 行 -136万×16≈2176万136 万 \times 16 \approx 2176 万136万×16≈2176万。如果行数据是 500B每页存 32 行 -136万×32≈4352万136 万 \times 32 \approx 4352 万136万×32≈4352万。如果行数据是 2KB每页存 8 行 -136万×8≈1088万136 万 \times 8 \approx 1088 万136万×8≈1088万。综合结论三层 B 树通常能存储2000 万 到 4000 万行数据。3. 如果数据量超过这个数怎么办如果数据量达到5000 万或1 亿B 树会自动增加高度变成4 层。4 层 B 树容量 11703×每页行数1170^3 \times \text{每页行数}11703×每页行数11703≈16亿1170^3 \approx 16 亿11703≈16亿个指针。即使每页只存 10 行也能存160 亿行数据。实际上4 层树通常能轻松支撑1 亿 ~ 10 亿级别的数据。为什么 MySQL 推荐单表数据控制在 2000 万以内并不是因为 3 层树存不下4 层也能存很多而是因为性能衰减虽然 B 树查找是O(log⁡N)O(\log N)O(logN)但 4 层树意味着每次查询需要 4 次磁盘 I/O如果没有缓存。虽然 InnoDB 有 Buffer Pool但随机 I/O 依然是瓶颈。维护成本数据量过大索引维护、备份恢复、DDL 操作如加字段的时间会显著变长甚至导致锁表时间过长影响业务。内存压力索引树很大无法完全放入内存导致磁盘 I/O 频繁。4. 影响容量的关键因素主键类型BIGINT(8 字节)容量较小。INT(4 字节)索引项变小每页能存更多指针容量翻倍。VARCHAR或UUID主键如果是长字符串索引项变大树的高度会迅速增加容量急剧下降。行数据大小行越小叶子节点存得越多总容量越大。行越大叶子节点存得越少总容量越小。页大小默认 16KB。如果修改为 32KB 或 64KB需重新编译 MySQL单页容量增加树的高度降低查询更快。总结3 层 B 树约2000 万 ~ 4000 万行数据取决于行大小。4 层 B 树约1 亿 ~ 10 亿行数据。实际建议虽然 4 层树能存很多数据但为了性能和可维护性通常建议单表数据量控制在2000 万以内。如果超过应考虑分库分表或归档历史数据。记忆口诀根节点 1170中间 1170 乘 1170叶子看行大小。三层两千万四层上亿行。主键选 INT容量翻一番。