面试题：InnoDB中一棵B+树能存多少行数据？

阅读本文大概须要 5 分钟。

做者：李平 | 来源：我的博客

1、InnoDB 一棵 B+ 树能够存放多少行数据？

InnoDB 一棵 B+ 树能够存放多少行数据？

这个问题的简单回答是：约 2 千万。

为何是这么多呢？

由于这是能够算出来的，要搞清楚这个问题，咱们先从 InnoDB 索引数据结构、数据组织方式提及。

咱们都知道计算机在存储数据的时候，有最小存储单元，这就比如咱们今天进行现金的流通最小单位是一毛。

在计算机中磁盘存储数据最小单元是扇区，一个扇区的大小是 512 字节，而文件系统（例如XFS/EXT4）他的最小单元是块，一个块的大小是 4k，而对于咱们的 InnoDB 存储引擎也有本身的最小储存单元——页（Page），一个页的大小是 16K。

2、下面几张图能够帮你理解最小存储单元

文件系统中一个文件大小只有1个字节，但不得不占磁盘上4KB的空间。

Innodb 的全部数据文件（后缀为 ibd 的文件），他的大小始终都是 16384（16k）的整数倍。

磁盘扇区、文件系统、InnoDB 存储引擎都有各自的最小存储单元。

在 MySQL 中咱们的 InnoDB 页的大小默认是 16k，固然也能够经过参数设置：

数据表中的数据都是存储在页中的，因此一个页中能存储多少行数据呢？

假设一行数据的大小是 1k，那么一个页能够存放 16 行这样的数据。

若是数据库只按这样的方式存储，那么如何查找数据就成为一个问题，由于咱们不知道要查找的数据存在哪一个页中，也不可能把全部的页遍历一遍，那样太慢了。

因此人们想了一个办法，用 B+ 树的方式组织这些数据。如图所示：

咱们先将数据记录按主键进行排序，分别存放在不一样的页中（为了便于理解咱们这里一个页中只存放 3 条记录，实际状况能够存放不少），除了存放数据的页之外，还有存放键值+指针的页，如图中page number=3 的页，该页存放键值和指向数据页的指针，这样的页由 N 个键值 + 指针组成。

固然它也是排好序的。

这样的数据组织形式，咱们称为索引组织表。

如今来看下，要查找一条数据，怎么查？

如 select * from user where id=5;

这里 id 是主键，咱们经过这棵 B+ 树来查找，首先找到根页，你怎么知道 user 表的根页在哪呢？

其实每张表的根页位置在表空间文件中是固定的，即 page number=3 的页（这点咱们下文还会进一步证实），找到根页后经过二分查找法，定位到 id=5 的数据应该在指针 P5 指向的页中，那么进一步去 page number=5 的页中查找，一样经过二分查询法便可找到 id=5 的记录：

| 5 | zhao2 | 27 |

如今咱们清楚了 InnoDB 中主键索引 B+ 树是如何组织数据、查询数据的，咱们总结一下：

一、InnoDB 存储引擎的最小存储单元是页，页能够用于存放数据也能够用于存放键值 + 指针，在 B+ 树中叶子节点存放数据，非叶子节点存放键值 + 指针。

二、索引组织表经过非叶子节点的二分查找法以及指针肯定数据在哪一个页中，进而在去数据页中查找到须要的数据；

3、那么回到咱们开始的问题，一般一棵 B+ 树能够存放多少行数据？

这里咱们先假设 B+ 树高为 2，即存在一个根节点和若干个叶子节点，那么这棵 B+ 树的存放总记录数为：根节点指针数 * 单个叶子节点记录行数。

上文咱们已经说明单个叶子节点（页）中的记录数 =16K/1K=16。（这里假设一行记录的数据大小为 1k，实际上如今不少互联网业务数据记录大小一般就是 1K 左右）。

那么如今咱们须要计算出非叶子节点能存放多少指针？

其实这也很好算，咱们假设主键 ID 为 bigint 类型，长度为 8 字节，而指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节，咱们一个页中能存放多少这样的单元，其实就表明有多少指针，即 16384/14=1170。

那么能够算出一棵高度为 2 的 B+ 树，能存放 1170*16=18720 条这样的数据记录。

根据一样的原理咱们能够算出一个高度为 3 的 B+ 树能够存放： 1170*1170*16=21902400 条这样的记录。

因此在 InnoDB 中 B+ 树高度通常为 1-3 层，它就能知足千万级的数据存储。

在查找数据时一次页的查找表明一次 IO，因此经过主键索引查询一般只须要 1-3 次 IO 操做便可查找到数据。

4、怎么获得 InnoDB 主键索引 B+ 树的高度？

上面咱们经过推断得出 B+ 树的高度一般是 1-3，下面咱们从另一个侧面证实这个结论。

在 InnoDB 的表空间文件中，约定 page numbe r为 3 的表明主键索引的根页，而在根页偏移量为 64 的地方存放了该 B+ 树的 page level。

若是 page level 为 1，树高为 2，page level 为 2，则树高为 3。

即 B+ 树的高度 =page level+1；

下面咱们将从实际环境中尝试找到这个 page level。

在实际操做以前，你能够经过 InnoDB 元数据表确认主键索引根页的 page number 为 3，你也能够从《InnoDB 存储引擎》这本书中获得确认。

执行结果：

能够看出数据库 dbt3 下的 customer 表、lineitem 表主键索引根页的 page number 均为 3，而其余的二级索引 page number 为 4。

关于二级索引与主键索引的区别请参考 MySQL 相关书籍，本文不在此介绍。

下面咱们对数据库表空间文件作想相关的解析：

由于主键索引 B+ 树的根页在整个表空间文件中的第 3 个页开始，因此能够算出它在文件中的偏移量：16384*3=49152（16384 为页大小）。

另外根据《InnoDB 存储引擎》中描述在根页的 64 偏移量位置前 2 个字节，保存了 page level 的值，所以咱们想要的 page level 的值在整个文件中的偏移量为：16384*3+64=49152+64=49216，前 2 个字节中。

接下来咱们用 hexdump 工具，查看表空间文件指定偏移量上的数据：

linetem 表的 page level 为 2，B+ 树高度为 page level+1=3；

region 表的 page level 为 0，B+ 树高度为 page level+1=1；

customer 表的 page level 为 2，B+ 树高度为 page level+1=3；

这三张表的数据量以下：

5、小结

lineitem 表的数据行数为 600 多万，B+ 树高度为 3，customer 表数据行数只有 15 万，B+ 树高度也为 3。

能够看出尽管数据量差别较大，这两个表树的高度都是 3，换句话说这两个表经过索引查询效率并无太大差别，由于都只须要作 3 次 IO。

那么若是有一张表行数是一千万，那么他的 B+ 树高度依旧是 3，查询效率仍然不会相差太大。

region 表只有 5 行数据，固然他的 B+ 树高度为 1。

6、最后回顾一道面试题

有一道 MySQL 的面试题，为何 MySQL 的索引要使用 B+ 树而不是其它树形结构？

好比 B 树？

如今这个问题的复杂版本能够参考本文；

他的简单版本回答是：

由于 B 树无论叶子节点仍是非叶子节点，都会保存数据，这样致使在非叶子节点中能保存的指针数量变少（有些资料也称为扇出），指针少的状况下要保存大量数据，只能增长树的高度，致使 IO 操做变多，查询性能变低。

7、总结

本文从一个问题出发，逐步介绍了 InnoDB 索引组织表的原理、查询方式，并结合已有知识，回答该问题，结合实践来证实。

固然为了表述简单易懂，文中忽略了一些细枝末节，好比一个页中不可能全部空间都用于存放数据，它还会存放一些少许的其余字段好比 page level，index number 等等，另外还有页的填充因子也致使一个页不可能所有用于保存数据。

关于二级索引数据存取方式能够参考 MySQL 相关书籍，他的要点是结合主键索引进行回表查询。

·END·

程序员的成长之路

路虽远，行则必至

本文原发于 同名微信公众号「程序员的成长之路」，回复「1024」你懂得，给个赞呗。

回复 [ 520 ] 领取程序员最佳学习方式

回复 [ 256 ] 查看 Java 程序员成长规划

往期精彩回顾

JSON WEB TOKEN 从原理到实战

很全！浅谈几种经常使用负载均衡架构

Elasticsearch如何作到亿级数据查询毫秒级返回？

Redis 到底能解决哪些问题

如何发现 Redis 热点 Key ，解决方案有哪些？

【漫画】程序员系列苏大强版表情包

揭秘 “全网影视 VIP 卡” 的背后产业链