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

答案：约2千万

为什么是这么多？

因为这是能够算进去的，要搞清楚这个问题，先从InnoDB索引数据结构、数据组织形式说起。

计算机在存储数据的时候，有最小存储单元，这就好比现金的流通最小单位是一毛。

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

上面几张图能够了解最小存储单元：

文件系统中一个文件大小只有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+树中叶子节点存放数据，非叶子节点寄存键值+指针。
  • 索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中，进而在去数据页中查找到须要的数据；

那么回到咱们开始的问题，通常一棵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存储引擎》这本书中失去确认。

能够看出数据库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等等，另外还有页的填充因子也导致一个页不可能全副用于保留数据。