为什么 MySQL 选择 B＋树作为存储引擎索引结构(12)

在估算前，我们需要事先假设两个数据:
假设非叶子节点中保存的页索引项，每一项的大小占 16 个字节。对于 16k 的一页而言，大约可以存储 1000(16k/16)条索引项。
假设叶子节点中保存的每条记录数据的平均大小为 160 个字节。对于 16k 的一页而言，大约可以存储 100(16k/160) 条记录。
综上：
对于 3 层的 B+ 树而言，其所能存储的数据量级：1000 *1000 * 100 ，大概108条
对于 4 层的 B+ 树而言，其所能存储的数据量级：1000 * 1000 * 1000 * 100 ，大概1011条
也就是说，一个 3 层的 B+ 树，在此种场景下，大约可以存储的数据量级就在千万级。因此该解决方案是可以解决我们最初提出来的问题的。下图是一个简单的总结。

本文插图
到此，我们也就回答完了三个问题。并通过回答这三个问题，探讨了面对读多写少场景时选择的 B+ 树存储引擎背后的一些选型过程。值得说明的是本文纯属个人学习过程中的一点思考和琢磨。有理解或表达不正确之处还请各位指正。