头条面试官：InnoDB中一棵B+树能够存放多少行数据？

InnoDB一棵B+树能够存放多少行数据？这个问题的简单回答是：约2千万。为何是这么多呢？由于这是能够算出来的，要搞清楚这个问题，咱们先从InnoDB索引数据结构、数据组织方式提及。
html

咱们都知道计算机在存储数据的时候，有最小存储单元，这就比如咱们今天进行现金的流通最小单位是一毛。在计算机中磁盘存储数据最小单元是扇区，一个扇区的大小是512字节，而文件系统（例如XFS/EXT4）他的最小单元是块，一个块的大小是4k，而对于咱们的InnoDB存储引擎也有本身的最小储存单元——页（Page），一个页的大小是16K。mysql

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

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

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

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

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

mysql> show variables like 'innodb_page_size';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.00 sec)

数据表中的数据都是存储在页中的，因此一个页中能存储多少行数据呢？假设一行数据的大小是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的记录：

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

InnoDB存储引擎的最小存储单元是页，页能够用于存放数据也能够用于存放键值+指针，在B+树中叶子节点存放数据，非叶子节点存放键值+指针。
索引组织表经过非叶子节点的二分查找法以及指针肯定数据在哪一个页中，进而在去数据页中查找到须要的数据；

那么回到咱们开始的问题，一般一棵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+树能够存放：

1170117016=21902400条这样的记录。因此在InnoDB中B+树高度通常为1-3层，它就能知足千万级的数据存储。在查找数据时一次页的查找表明一次IO，因此经过主键索引查询一般只须要1-3次IO操做便可查找到数据。

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

上面咱们经过推断得出B+树的高度一般是1-3，下面咱们从另一个侧面证实这个结论。在InnoDB的表空间文件中，约定page number为3的表明主键索引的根页，而在根页偏移量为64的地方存放了该B+树的page level。若是page level为1，树高为2，page level为2，则树高为3。即B+树的高度=page level+1；下面咱们将从实际环境中尝试找到这个page level。

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

SELECTb.name, a.name, index_id, type, a.space, a.PAGE_NOFROMinformation_schema.INNODB_SYS_INDEXES a,information_schema.INNODB_SYS_TABLES bWHEREa.table_id = b.table_id AND a.space <> 0;

执行结果：

能够看出数据库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；

这三张表的数据量以下：

总结：

lineitem表的数据行数为600多万，B+树高度为3，customer表数据行数只有15万，B+树高度也为3。能够看出尽管数据量差别较大，这两个表树的高度都是3，换句话说这两个表经过索引查询效率并无太大差别，由于都只须要作3次IO。那么若是有一张表行数是一千万，那么他的B+树高度依旧是3，查询效率仍然不会相差太大。

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

最后回顾一道面试题

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

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

他的简单版本回答是：

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

小结

本文从一个问题出发，逐步介绍了InnoDB索引组织表的原理、查询方式，并结合已有知识，回答该问题，结合实践来证实。固然为了表述简单易懂，文中忽略了一些细枝末节，好比一个页中不可能全部空间都用于存放数据，它还会存放一些少许的其余字段好比page level，index number等等，另外还有页的填充因子也致使一个页不可能所有用于保存数据。关于二级索引数据存取方式能够参考MySQL相关书籍，他的要点是结合主键索引进行回表查询。

来源：https://www.cnblogs.com/leefreeman/p/8315844.html

本文分享自微信公众号 - 会呼吸的Coder（BreathCoder）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。