正文
页格式这块的内容，我在官网翻了好久，硬是没找到🤧。。。。不知道是没写还是我眼瞎，有找到的朋友希望可以在评论区帮我挂出来😋。
所以上面页格式的表格内容主要是基于一些博客中学习总结的。
另外，当新记录插入到 InnoDB 聚集索引中时，InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录，则页大约可用 1/2 到 15/16 的空间。
参考文档：https://dev.mysql.com/doc/refman/5.7/en/innodb-physical-structure.html
除了
User Records
和
Free Space
以外所占用的内存是 38+56+26+8=128字节，每一页留给用户数据的空间就还剩
（保留了1/16）。
当然，这是最小值，因为我们没有考虑页目录。页目录留在后面根据再去考虑，这个得根据表字段来计算。
行格式
首先，我觉得有必要提一嘴，MySQL5.6的默认行格式为COMPACT(紧凑)，5.7及以后的默认行格式为DYNAMIC(动态)，不同的行格式存储的方式也是有区别的，还有其他的两种行格式，本文后续的内容主要是基于DYNAMIC(动态)进行讲解的。
官方文档链接：https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html#innodb-compact-row-format-characteristics（包括下面的行格式内容大都可以在里面找到）
每行记录都包含以下这些信息，其中大都是可以从官方文档当中找到的。我这里写的不是特别详细，仅写了一些能够我们计算空间的知识，更详细内容可以去网上搜索 “MySQL 行格式”。
示意图：
另外还有几点需要注意：
溢出页（外部页）的存储
注意：这一点是DYNAMIC的特性。
当使用 DYNAMIC 创建表时，InnoDB 会将较长的可变长度列（比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型）的值剥离出来，存储到一个
溢出页
上，只在该列上保留一个 20 字节的指针指向溢出页。
而 COMPACT 行格式（MySQL5.6默认格式）则是将前 768 个字节和 20 字节的指针存储在 B+ 树节点的记录中，其余部分存储在溢出页上。
列是否存储在页外取决于页大小和行的总大小。当一行太长时，选择最长的列进行页外存储，直到聚集索引记录适合 B+ 树页（文档里没说具体是多少😅）。小于或等于 40 字节的 TEXT 和 BLOB 直接存储在行内，不会分页。
优点
DYNAMIC 行格式避免了用大量数据填充 B+ 树节点从而导致长列的问题。
DYNAMIC 行格式的想法是，如果长数据值的一部分存储在页外，则通常将整个值存储在页外是最有效的。
使用 DYNAMIC 格式，较短的列会尽可能保留在 B+ 树节点中，从而最大限度地减少给定行所需的溢出页数。
字符编码不同情况下的存储
char 、varchar、text 等需要设置字符编码的类型，在计算所占用空间时，需要考虑不同编码所占用的空间。
varchar、text等类型会有长度字段列表来记录他们所占用的长度，但char是固定长度的类型，情况比较特殊，假设字段 name 的类型为 char(10) ，则有以下情况：
-
对于长度固定的字符编码（比如ASCII码），字段 name 将以固定长度格式存储，ASCII码每个字符占一个字节，那 name 就是占用 10 个字节。
-
对于长度不固定的字符编码（比如utf8mb4），至少将为 name 保留 10 个字节。如果可以，InnoDB会通过修剪尾部空格空间的方式来将其存到 10 个字节中。
如果空格剪完了还存不下，则将尾随空格修剪为 _列值字节长度的最小值_（一般是 1 字节）。
列的最大长度为： 字符编码的最大字符长度×N字符编码的最大字符长度 \times N字符编码的最大字符长度×N，比如 name 字段的编码为 utf8mb4，那就是 4×10。
-
大于或等于 768 字节的 char 列会被看成是可变长度字段（就像varchar一样），可以跨页存储。例如，utf8mb4 字符集的最大字节长度为 4，则 char(255) 列将可能会超过 768 个字节，进行跨页存储。
说实话对char的这个设计我是不太理解的，尽管看了很久，包括官方文档和一些博客🤧，希望懂的同学可以在评论区解惑：
对于长度不固定的字符编码这块，char是不是有点像是一个长度可变的类型了？我们常用的 utf8mb4，占用为 1 ~ 4 字节，那么 char(10) 所占用的空间就是 10 ~ 40 字节，这个变化还是挺大的啊，但是它并没有留足够的空间给它，也没有使用可变长度字段列表去记录char字段的空间占用情况，就很特殊？
开始计算
好了，我们已经知道每一页当中具体存储的东西了，现在我们已经具备计算能力了。
由于页的剩余空间我已经在上面页格式的地方计算过了，每页会剩余 15232 字节可用，下面我们直接计算行。
非叶子节点计算
单个节点计算
索引页就是存索引的节点，也就是非叶子节点。
每一条索引记录当中都包含了
当前索引的值
、
一个 6字节 的指针信息
、
一个 5 字节的行标头
，用来指向下一层数据页的指针。
索引记录当中的指针占用空间我没在官方文档里找到😭，这个 6 字节是我参考其他博文的，他们说源码里写的是6字节，但具体在哪一段源码我也不知道😭。
希望知道的同学可以在评论区解惑。
假设我们的主键id为 bigint 型，也就是8个字节，那索引页中每行数据占用的空间就等于 8+6+5=19字节。每页可以存 15232÷19≈801 条索引数据。
那算上页目录的话，按每个槽平均6条数据计算的话，至少有 801÷6≈134 个槽，需要占用 268 字节的空间。
把存数据的空间分一点给槽的话，我算出来大约可以存 787 条索引数据。
如果是主键是 int 型的话，那可以存更多，大约有 993 条索引数据。
前两层非叶子节点计算
在 B+ 树当中，当一个节点索引记录为 N 条时，它就会有 N 个子节点。由于我们 3 层B+树的前两层都是索引记录，第一层根节点有 N 条索引记录，那第二层就会有 N 个节点，每个节点数据类型与根节点一致，仍然可以再存 N 条记录，第三层的节点个数就会等于
。
则有：
