InnoDb 的存储引擎结构
最后我们再回到InnoDb存储引擎了解InnoDb 的存储引擎基本结构。
如果想要详细的了解这部分的结构，建议阅读**《Mysql是怎么样运行》**这本书里面对于整个Mysql内部结构做了非常详细的介绍，对于理解InnoDb的存储结构十分有帮助。
下面为InnoDb存储引擎的数据存储简易结构图，更加详细的结构在视频中并没有展开，另外如果展开讲述的话一篇文章也是远远不够的，所以这里只能是大致了解：
表空间：数据表在磁盘上的存储空间，默认情况下所有表的数据存在共享表空间，当然为了权限的使用每一个表的数据也可以放在独占的表空间，
段：段分为叶子节点段和非叶子节点段，叶子节点段叫做B+树段节点，而非叶子节点就是索引页了。
区：区通常由64个页组成，每一个段里面对应很多区，一个区段大小是1M，一般由连续段数据页组成，但是一般一次申请为申请3-4个。（需要考虑内存的承受能力）
数据页：**页是InnoDb的最小数据单位，默认为16kb，**一个数据页是B+树的节点，最关键的是数据页的设计考虑到了SSD和机械硬盘的设计，一个机械硬盘最小的读写单位是512KB，一个SSD最小的读写单位是4b，所以16KB是他们的倍数，可以节省空间。
数据行：数据行分为2种类型，包括inf和sup两个数据行，不管一个表是否有数据行，至少会有这两个数据行，同时每一行默认会隐藏三个字段，Trx Id多用于事务的控制。
为什么数据页不能太大，也不能太小？
回答：如果数据页太大，那么每次读取数据页如果只是查找几行数据，那么会浪费大量的计算机资源，因为IO的对于数据库系统是需要尽量避免的，如果数据页太小由于磁盘最小的读取单元存在限制，也可能会因为多次读取导致性能极速下降，而数据页太大如果需要的数据仅仅几条又十分浪费IO的性能。
所以mysql在设计数据页大小的时候考虑的固态磁盘和机械磁盘的读取单位的折中。
数据行
为了防止读者误解下面的所有的介绍都是针对InnoDb的存储引擎以及mysql5.7的版本中进行介绍。
数据行格式
提示：这里先提前打一下预防针，其实技术的改进都是细节的改进，了解完之后会发现其实也就那么一回事，但是关键在于魔鬼藏在细节中，所以需要小心区分对待。
数据行的内容比较特殊，由于历史的原因他进行了演变，也为了方便理解，我们需要记住mysql的数据行有两种格式，他们分别由Antelope 和 Barracuda 两种格式，为了方便理解我们称这两个人为AB吧，在mysql的数据行格式一共有四种类型，但是由于其中REDUNDANT和COMPACT两种格式是新版本中早就不再使用较老的格式，但是在面试中可能被问到所以有必要进行理解：
Antelope：包含REDUNDANT和COMPACT.
Barracuda：包含DYNAMIC（5.0之后以及8.0默认的建表行格式）和COMPRESSED（压缩格式）
如果需要了解当前mysql版本的默认行格式，可以使用
SHOW VARIABLES LIKE "InnoDb_default_row_format"的命令进行查看。
下面我们按照从旧到新到顺序来看一下行格式演变。
A大叔的格式：
REDUNDANT：REDUNDANT格式英文名称翻译过来叫做“冗余”格式，他是mysql5.0之前的默认行格式，需要注意到是下面的示例图分隔符实际是不存在的，在实际存储到过程中都是按照特定编码进行紧凑存储的。
这样就会带来一个问题，比如我们要找到col1或者找到coln要怎么查？所以最前端的字段偏移列表的作用就是来帮助mysql快速定位到具体要查找到列的，但是我们又需要注意字段偏移列表使用了逆序存储的方式进行处理，我们直接通过一个例子进行解释字段偏移列表的作用：
再次强调字段偏移列表不是固定记录变长列长度的，而是存放的是相邻两个列之间的偏移长度，假设当前有三列varchar数据，顺序存储长度分别为1，2，3，按照字段偏移列表的规则为1，3（3-1=2），6（6-3=3），这几个值字段偏移列表逆序存储同时，真实数据按照16进制表示，所以最终的结果为：06 03 01（注意中间空格为了方面阅读加入，实际是紧凑的排列060301）
header部分比较好理解，比如表示字段偏移列表的单位以及记录列的数量，以及一个十分重要的元素：下一个数据行的地址信息等。
rowId在之前的笔记中提到过，如果在建表的时候没有指定主键，那么mysql就会使用这个rowId作为隐藏的主键，TxID用于事务控制，然后是roll pointer用于undo log回滚实现MVCC的机制，最后便是col1，col2，col3的列是真实的数据。
如果还是好奇为什么字段偏移列表要逆序存储，其实仔细观察上面的行格式结构可以看出端倪，以
roll point为界限，左边是头信息和字段偏移列表，右边是真实数据。官方说法是把记录分为记录头信息和真实数据两部分，而使用逆序存储的方式可以让长度和真实数据列“对称”，指针向左移，一个指针向右移动，效率高一些。
B大叔的格式：
COMPACT格式：这个格式比REDUNDANT精致很多，可以看到上面的字段偏移列表不是很直观，每次都需要进行一次减法才能算出列的真实长度，所以Compact使用了变长字段列表改进，变长字段列表直接存储列的长度并且以逆序的方式存储，并且在此基础上加入了NULL值列表来维护每一列是否为NULL，使用位表的方式标志每一列是否为NULL，0为NULL，1为非NULL，并且同样是逆序存储。
记录头的信息差异并不是特别大，所以这里直接忽略了，重点关注“变长字段列表”和“NULL值列表”的改动，技术的进步总是微小但是十分有效的。
COMPRESSED的优点是对于过大的页会进行压缩存储，但是压缩存储的问题是读取的时候需要解包读取，会更多耗费一定的性能。
最后我们可以从下面的图看到基本的行格式的具体特性，这个表来自于mysql5.7的官方文档，地址为：dev.mysql.com/doc/refman/…：
| 行格式 | 紧凑存储特性 | 增强的可变长度色谱柱存储 | 大索引键前缀支持 | Compression Support | 支持的 table 空间类型 | 所需文件格式 |
REDUNDANT |
No | No | No | No | 系统，每 table 文件，常规 | Antelope or Barracuda |
COMPACT |
Yes | No | No | No | 系统，每 table 文件，常规 | Antelope or Barracuda |
DYNAMIC |
Yes | Yes | Yes | No | 系统，每 table 文件，常规 | Barracuda |
COMPRESSED |
Yes | Yes | Yes | Yes | file-per-table, general | Barracuda |
可变列和不可变列
我们都知道Mysql支持的数据类型是很多的比如varchar，char，int，blob，text等等。这里我们重点关注变长列的和不变长列的数据类型，变长列指的是指定长度和实际长度不一致的列比如varchar，其中的var单词就是代表variableke（可变），所以称之为可变列，不变长列也就是字符长度固定的列char，我们发现无论是学校学习还是各种网上百科，通常介绍会认为char是固定长度的，varchar是不固定长度的。
真的是这样吗？然而随着时代的发展char其实也发生了变化这里，可以看mysql5.7的文档解释：
InnoDb将长度大于或等于 768 字节的固定长度字段编码为可变长度字段在页外存储。例如 CHAR(255)如果字符集的最大字节长度大于 3，则列可能超过 768 个字节，就像utf8mb4。
原文：
InnoDbencodes fixed-length fields greater than or equal to 768 bytes in length as variable-length fields, which can be stored off-page. For example, aCHAR(255)column can exceed 768 bytes if the maximum byte length of the character set is greater than 3, as it is withutf8mb4.
一个varchar最大长度是多少
在mysql4.1之前，varchar的最大值为255，这大概也是很多数据库管理工具默认给varchar(255)的一个原因。
在5.0以上的 版本中varchar最多可以占用65535个字节，为什么是65535？是因为InnoDb最多给一个字段分配2个字节，也就是说一个varchar最多只有16位，2的16次方-1= 65535（受到二进制补位的影响）。
注意这里说的是字节而不是字符，由于字符串实际上是通过字节进行特殊编码翻译而来，所以对于一些变长编码的存储长度是实时变化的，比如utf8mb4的编码最多占4个字节，套入上面的数据65535/4约等于16383个字符。
所以针对utf8mb4编码的varchar列最大长度为16383？真的是这样么？实际上这个值也是一个参考，虽然理论上确实应该存储这么多数据，但是实际上是肯定长度达不到16383的，至于理由其实可以实际建立一个表尝试，会发现创建失败或者修改字段失败。
这和mysql的底层数据结构有关系，由于变长字段需要记录长度，同时mysql为了记录信息需要用一些额外的记录空间进行存储。
备注：length函数不是记录字符的个数，而是实际占用的长度，由于中文需要3个字符长度存储，所以实际存储的长度为63000/3=21000
提示：如果修改报错内容如下
1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
写在最后
从Mysql的B+树结构和其他可能的数据库数据结构设计，可以发现B+树是多种数据结构兼容和平衡，而Mysql在实践的过程有还是做了改进，理论和实践之间总是有某种差异
