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

引入了将磁盘划分成一个一个
固定大小连续块
的概念
块内数据仍然按照有序、顺序写存储
：块内仍然对每条记录保存两个信息：该记录写到磁盘的哪个位置 offset、该条记录占多长 size
块间数据有序，每块需要保存两个信息
：块编号 no、该块保存的最小记录值 min
在引入这个块的概念后，我们看看当执行范围查找、排序等操作时，大部分情况下可以减少 IO 的次数，因为一次读取的一块数据，而一块中的数据包含多条记录。如果所涉及的数据在一块内的话，多条数据就只需要读取一次磁盘。所以在这种场景下，性能也会有所改善。
整体大致的结构如下图所示：

本文插图
同时，我们还有两个遗留问题需要解决:
1. 块的大小定多大呢？
2. 块索引存不存？怎么存？
针对第一个问题:
块大小定多大？
，我们可以辩证的来看。
如果块大小越大
，那么一块能保存的数据就越多，因此同等数据量级的条件下我们需要的块就越少，近而需要维护的
块索引也就越少
。但读写每条记录的时候额外读写的空间会越大(按照块读写) ，
因此读写效率越低
。
如果块大小越小
，那么一块能保存的数据就越少，因此同等数据量级的条件下我们需要的块就越多，近而需要维护的
块索引也就越多
。但读写每条记录的时候额外读写的空间会越小(按照块读写) ，
因此读写效率越高
【为什么 MySQL 选择 B＋树作为存储引擎索引结构】 。
到这儿总算看出来了，其实
块大小定多大
就是一个折中问题。那我们怎么来选择呢？
别忘了，我们的数据存储在磁盘，同时我们的应用时跑在操作系统上层，我们在这儿就想
怎么让操作系统为我们的应用服务的更好呢？
简而言之就是更好的利用操作系统的特性，让其发挥出最大的价值。我们每次读写数据都会涉及到磁盘操作，例如读写磁盘、刷盘等，而在数据写到磁盘前，数据会先写到内存中，在操作系统中管理内存时，有一个
页
的概念。操作系统读写磁盘、刷盘时机都和
管理内存的页
有不可分割的关系。因此那我们这块要不为了更好利用操作系统，
就将操作系统页做为基本单位来确定块的大小
，最简单也就是一块大小等于一页大小(默认 4k) 。更大也可以是 8k、16k、32k 等等。
其实到这儿，我们也就回想起来了， InnoDB 中默认的页大小就是16k；而在 BoltDB 中，默认的页大小就是操作系统的页大小 4k 。