概述

• InnoDB 的数据是按「数据页」为单位来读写的，也就是说，当需要读一条记录的时候，并不是将这个记录本身从磁盘读出来，而是以页为单位，将其整体读入内存。
• 数据库的 I/O 操作的最小单位是页，InnoDB 数据页的默认大小是 16KB，意味着数据库每次读写都是以 16KB 为单位的

数据页结构

• 数据页与数据页之间通过File Header指针连接，形成一个双向链表。物理上不连续但逻辑上连续。
  

User Records 的结构

• 数据页中的记录与记录是按照主键顺序组成单向链表，使得插入、删除方便。检索效率不高，于是数据页中有一个页目录起到快速检索的作用。
• 数据页中的数据划分为几个组，每一个组对应一个槽。
• 每个记录组的最后一条记录就是组内最大的记录，并且最后一条记录的头信息中会存储该组一共有多少条记录（粉丝的）
• 页目录用来存储每组最后一条记录的地址偏移量（也叫做槽），每个槽相当于指针指向了不同组的最后一个记录。
• 页目录就是由多个槽组成的，槽相当于分组记录的索引，我们通过槽查找记录时，定位到槽后，再遍历槽内的所有记录，找到对应的记录

B+ 树是如何进行查询的？

• 当我们需要存储大量的记录时，就需要多个数据页，数据页与数据页通过指针相连接组成双向链表。由于一个数据页大小为16kb,而一次IO，一次性加载一个节点，每个节点都是一个数据页。从根节点进行查询，一层一层的查询由于B+Tree的只有叶子节点存放数据，因此当遍历到叶子节点后，就会找到相应的索引值，进而找到数据。
  

B树、B+树、二叉树

二叉树：

• 每个节点只能有 2 个子节点，那么当节点个数越多的时候，树的高度也会相应变高，这样就会增加磁盘的 I/O 次数，从而影响数据查询的效率。

B 树：

• 每一个节点最多可以包括 M 个子节点。
• B 树的每个节点都包含数据（索引+记录），而用户的记录数据的大小很有可能远远超过了索引数据，这就需要花费更多的磁盘 I/O 操作次数来读到「有用的索引数据」。
• 使用 B 树来做范围查询的话，需要使用中序遍历，这会涉及多个节点的磁盘 I/O 问题，从而导致整体速度下降。

B+树：

• 叶子节点（最底部的节点）才会存放实际数据（索引+记录），非叶子节点只会存放索引；
• 所有索引都会在叶子节点出现，叶子节点之间构成一个有序链表；
• 非叶子节点的索引也会同时存在在子节点中，并且是在子节点中所有索引的最大（或最小）。
• 非叶子节点中有多少个子节点，就有多少个索引；

MySQL 默认的存储引擎 InnoDB 采用的是 B+ 作为索引的数据结构的原因？

• B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O次数会更少。
• B+ 树有大量的冗余节点（所有非叶子节点都是冗余索引），这些冗余索引让 B+ 树在插入、删除的效率都更高，比如删除根节点的时候，不会像 B 树那样会发生复杂的树的变化；
• B+ 树叶子节点之间用链表连接了起来，有利于范围查询，而 B 树要实现范围查询，因此只能通过树的遍历来完成范围查询，这会涉及多个节点的磁盘 I/O 操作，范围查询效率不如 B+ 树。