innodb页是16kb物理单元，由file header（38字节）、user records、file trailer（8字节）硬性拼接；prev/next page指针构成双向链表，page directory通过分组槽位支持二分查找；行溢出触发条件为单行未压缩长度＞8000字节且使用compact/dynamic格式；page_garbage统计已删记录残留空间，超4kb将触发页重组。
Page页结构的物理组成和关键字段
MySQL InnoDB中一个页是16KB的固定大小块，不是“逻辑容器”而是真实写入磁盘的二进制单元。它由三部分硬性拼接而成：File Header（38字节）、User Records（主体数据区）、File Trailer（8字节）。中间没有空隙，也没有自动对齐填充。
真正影响你查数据快慢的，是File Header里的两个指针：Prev Page和Next Page——它们让页在B+树同层或链表中形成双向链表；而Page Directory（页目录）藏在页尾前、记录区后，是一组2字节槽位数组，用于二分查找记录位置。这个目录不是每条记录都有槽，而是按主键顺序把记录分组（每组4–8条），只在每组最大记录上设槽。
常见误读是以为页内记录按插入顺序物理排列。实际上：初始插入时可能接近有序，但一旦有DELETE或UPDATE，空洞产生，新记录会插在PAGE_FREE链表指向的位置，物理顺序就乱了——逻辑顺序全靠单向链表（next_record指针）和页目录维持。
行溢出发生的触发条件与格式差异
行溢出不是“数据太大就溢出”，而是当**单行未压缩原始长度 > 8000 字节**（约一半页大小）且使用COMPACT或DYNAMIC行格式时，InnoDB才启动溢出处理。注意：这个阈值和innodb_page_size无关，是硬编码的临界值。
不同行格式行为差别极大：
-
COMPACT：在当前页保留768字节前缀 + 20字节指针，其余存到独立的溢出页（BLOB页），读取时需二次I/O -
DYNAMIC：当前页只存20字节指针，全部大字段内容外置，主键查询不带大字段时更快 -
COMPRESSED：先压缩再判断是否溢出，可能避免溢出，但CPU开销上升
一个容易踩的坑：TEXT/BLOB列即使值为空（''），只要定义了，就会参与长度计算；而NULL值本身只占NULL bitmap里的1位，不计入8000字节阈值。
如何验证某行是否发生溢出
直接查information_schema.INNODB_SYS_COLUMNS只能看到列定义，无法判断实际存储形态。更可靠的方式是用innodb_ruby工具或解析ibd文件，但生产环境通常用间接方法：
- 执行
SELECT LENGTH(col) FROM tbl WHERE pk = ?，若返回值远大于你预期的“可见内容长度”，说明可能存了溢出指针而非真实数据 - 开启
innodb_monitor_output并观察Buffer pool hit rate和Pages read ahead突增，大量溢出行会导致预读失效、随机I/O升高 - 建表时显式指定
ROW_FORMAT=DYNAMIC并搭配innodb_file_per_table=ON，可减少因格式默认值（5.7以前是COMPACT）导致的意外溢出
注意：SHOW CREATE TABLE输出里的ROW_FORMAT只是声明，实际存储格式还受innodb_file_format（已废弃）和innodb_large_prefix（影响索引前缀长度）等隐含参数影响。
页内空间碎片与PAGE_GARBAGE的实际意义
PAGE_GARBAGE字段记录的是该页中所有已删除记录（DELETE标记但未清理）占用的总字节数。它不等于空闲空间，因为PAGE_FREE链表管理的是连续空闲块，而PAGE_GARBAGE是离散的“尸体残留”。当PAGE_GARBAGE超过页大小的1/4（约4KB），InnoDB会在后续INSERT时触发页合并（page reorganization），把有效记录挪到一起，回收碎片。
这意味着：频繁DELETE+INSERT小记录的表，即使总数据量不大，页内碎片也可能很高，SELECT COUNT(*)变慢、缓冲池命中率下降——这不是索引问题，而是页级物理布局退化。此时OPTIMIZE TABLE或ALTER TABLE ... FORCE能重建页结构，但会加锁，需评估业务窗口。
真正难调试的是PAGE_LEVEL和PAGE_INDEX_ID这类字段：它们不出现在任何SQL接口里，只能通过hexdump或innodb_ruby -r page解析原始页数据才能看到。线上定位深层性能问题时，这些才是关键线索。
