InnoDB 行格式详解：DYNAMIC / COMPACT / COMPRESSED / REDUNDANT

一、行格式总览

1.1 四种行格式与默认值

加粗要点：8.0 默认行格式是 DYNAMIC，由系统变量 innodb_default_row_format 控制（默认值 DYNAMIC）。

1.2 查看与指定行格式

— 查看某张表的行格式
SHOW TABLE STATUS LIKE 't1'\\G — 看 Row_format 字段
SHOW CREATE TABLE t1\\G — 看 ROW_FORMAT 子句

— 建表 / 改表时指定行格式
CREATE TABLE t1 (id INT PRIMARY KEY, name VARCHAR(100)) ROW_FORMAT=DYNAMIC;
ALTER TABLE t1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;

1.3 本系列分析的基线

上篇InnoDB 页结构详解：页类型、页头页尾、数据行与页目录-CSDN博客 分析的"额外信息 + 真实数据"结构，就是 DYNAMIC 行格式。本篇以它为主线，再看另外三种的差异。

二、DYNAMIC 行格式（默认）

2.1 总体结构

COMPACT / DYNAMIC 行格式（一条记录的物理布局）

记录起点
│
▼
┌──────────────────┬─────────────┬──────────────────┬─────────────────────────────┐
│ 变长字段长度列表 │ NULL 值位图 │ 记录头（5B/40bit） │ 真实数据（列值 + 隐藏列） │
│ （按列逆序，2B/列）│ （1bit/列） │ heap_no/next_record │ DB_TRX_ID(6) DB_ROLL_PTR(7)…│
└──────────────────┴─────────────┴──────────────────┴─────────────────────────────┘
│
└── next_record ──▶ 下一条记录的"真实数据起点"

2.2 真实数据里到底有什么

主键   DB_TRX_ID    DB_ROLL_PTR    其余列

当表中存在主键时直接将对应的主键放在前面；如果不存在主键，但是存在非空唯一键，将第一个非空唯一键作为主键组织数据；如果两者都没有，则自动生成主键。

对于二级索引树，放在第一个位置的是对应的索引，数据是主键 (InnoDB下）

三、NULL 值列表的工作原理

3.1 三条规则

示例：表 t(id INT NOT NULL, name VARCHAR(10) NULL, age INT NULL, addr VARCHAR(20) NULL)
→ 可空列按定义顺序：name、age、addr（3 列 → 位图占 3 bit，不足 1 字节按 1 字节对齐？）
位图（逆序）：addr(bit2) age(bit1) name(bit0)
若 name=NULL, age=20, addr='NJ' → 位图 = 001（仅 bit0=1）

NULL 位图按字节存放，实际占用的字节数 = 向上取整（可空列数 / 8）。

3.2 为什么"自右向左"？

• 记录头是"额外信息"与"真实数据"的分界线，next_record 指向交界处；
• 设计目标：向右直接读数据（按列顺序），向左读额外信息；
• 变长长度列表、NULL 位图都逆序存放，正是为了配合"向左解析"的方向。

3.3 NULL 位图里的 bit，怎么知道对应哪一列？

靠表结构元数据，不需要在行内额外存列号：

好处：既是空间节省（NULL 不占盘），也是语义精确（用位图区分"NULL"与值为"NULL"，不会混淆）。

四、变长字段长度列表

4.1 哪些列算"变长字段"

。

4.2 1~2 字节长度规则

变长字段长度列表逆序存放：第一个变长列的长度在列表最右端。每个字段长度占 1 或 2 字节，判定规则：

（ InnoDB规定按照磁盘按照大端存储，但是单个字节内无论大小端都是 MSB –> LSB，作者犯蠢了 )

存储示例：某变长列实际长度 = 257 字节（0x0101，>255）
→ 2 字节表示：0000 0001 1000 0001

读取：先读第一字节（自右向左）1000 0001 ，发现最高位是 1 → 这是 2 字节表示（InnoDB规定存储方式为大端）
→ 长度 = (000 0001) << 8 | 0000 0001 = 0x101 = 257

长度 = (第一字节的低 7 位) << 8 | 第二字节的 8 位

4.3 问：2 字节能到 2¹⁵-1 ，大于 16KB （一个页的大小），一个页会不会连一行也放不下？

InnoDB 明确规定：一个页至少要能放下两行记录（否则 B+Tree 每页只有 1 条记录，树就退化成链表）。由此推出行大小约束：

16KB 页 → 行最大 ≈ 半页 ≈ 8KB（实际约 8126 字节，还要扣行开销）

对于超长字段，dynamic 的溢出处理是将数据放在溢出页中，对应字段只存放溢出页的 20 字节地址

DYNAMIC 行格式：超长字段（如 TEXT/BLOB/LONGTEXT）
┌─────────────────────────┐
│ 行内：20 字节指针 │ ──▶ 指向溢出页
│ （该列完整数据不留在行内） │
└─────────────────────────┘

溢出页 = BLOB 页（FIL_PAGE_TYPE_BLOB），数据过大时可由多个溢出页链式存放

• 特点：整列数据全部放入溢出页，行内只保留 20 字节的指针（指向溢出页位置）；
• 这样行大小始终可控，不会因为一个大字段撑破"半页"约束；
• 溢出与否的本质判断：该列实际长度是否超过行内可容纳的阈值；溢出后行内表现为指针，变长长度列表记录的是行内实际保留部分的长度。

五、COMPACT 行格式：

5.1 与 DYNAMIC 的唯一区别

COMPACT 与 DYNAMIC 的额外信息、NULL 列表、记录头完全一致，唯一的差别在超长字段的处理：

COMPACT：行内 = [前 768 字节数据][20 字节溢出页指针]
即"768 + 20"，剩余部分在溢出页

5.2 768 字节前缀的价值

• 保留了长字段的前 768 字节在行内，可支持前缀索引/前缀匹配（不必每次都进溢出页）；
• 对"小字段混合大字段"的表，某些查询可以只读行内前缀就返回。

5.3 何时选 COMPACT

• 需要兼容老版本行为；
• 业务上对长文本有前缀查询需求；
• 默认建议仍用 DYNAMIC（官方默认），除非有明确理由。

六、COMPRESSED 行格式：DYNAMIC + 压缩

6.1 压缩原理

• 行结构与 DYNAMIC 完全相同（包括溢出处理方式）；
• 额外做的事：对数据（含页）进行 zlib 压缩，减少磁盘空间占用；
• 通过 ROW_FORMAT=COMPRESSED + KEY_BLOCK_SIZE=N 启用（N 为压缩页大小）。

6.2 时间换空间

6.3 注意点

• 适合空间紧张、CPU 富余、以顺序扫描为主的场景（如归档表）；
• 不适合写放大严重、CPU 已是瓶颈的 OLTP 核心表；
• 压缩页类型为 FIL_PAGE_COMPRESSED，与 8.0 的"表空间页压缩（COMPRESSION='zlib'）"是不同机制，不要混淆。

七、REDUNDANT 行格式：历史遗留

• InnoDB 最早的格式（MySQL 4.1 时代），只为兼容旧表而存在，新表不应使用；
• 读取效率、空间利用率都不如 COMPACT 系列，官方不建议新表使用。