varchar(255)比varchar(32)更易抬高行偏移，因前者使长度数组和偏移指针更可能升为2字节，并加剧页内碎片，降低单页记录数、抬升b+树高度、增加i/o次数。
字段长度设得过大，会直接抬高行偏移、降低页内记录密度、增加单次磁盘读取的数据量——这不是“省事”，而是悄悄给I/O加负重。
为什么VARCHAR(255)比VARCHAR(32)更容易触发额外I/O
InnoDB在页内组织变长字段时，会为每个VARCHAR预留长度数组空间，并用偏移指针跳转到行末的实际值位置。字段定义上限越大，InnoDB越倾向分配更宽松的间隙：一方面长度数组本身可能从1字节升为2字节（当最大长度≥256），另一方面多个大VARCHAR并存时，指针位宽膨胀+值区碎片化，导致同一数据页能塞下的记录数明显下降。结果就是B+树层级变高、查询需要更多页读取——Avg_row_length查出来比理论最小和高出一倍，基本就坐实了这个问题。
- 用
SHOW TABLE STATUS LIKE 'table_name'对比Avg_row_length与各字段理论宽度之和（含NULL位图、长度数组、指针开销） - 同一行中混用
VARCHAR(255)和VARCHAR(5)会加剧页内空洞，InnoDB打包效率骤降 -
TEXT/BLOB不光拉高偏移，还会强制行内只存20字节指针、主体外存，进一步放大I/O次数
CHAR和VARCHAR怎么选才不浪费页空间
固定长度字段用CHAR反而更省：比如订单号恒为32位十六进制，CHAR(32)比VARCHAR(255)少存长度数组、无偏移跳转、页内对齐干净；而用户昵称这种真有长度波动的，就按业务最大合理值设VARCHAR，别留余量。
- 身份证号、UUID、API密钥等固定格式字段，优先用
CHAR而非VARCHAR - 中文昵称≤20字就用
VARCHAR(20)，英文用户名≤32字符就用VARCHAR(32) - 避免全表字段统一用
VARCHAR(255)——这在建表脚本里看着省事，上线后innodb_buffer_pool_reads会默默涨
NULL列对I/O的影响常被低估
每行只要有一个NULL列，InnoDB就得额外分配NULL位图（1字节管8列），且该位图位置固定在记录头之后、固定字段之前，会整体后推所有后续字段的偏移地址。字段越多、NULL列越分散，偏移指针就越容易从1字节升为2字节，进一步挤占页内有效空间。
- 能用默认值（如
created_at设DEFAULT CURRENT_TIMESTAMP）就别允许NULL - 确实需要标识“未设置”的场景，考虑用特殊值（如
0、''、'1970-01-01'）替代NULL，尤其在高频查询的宽表中 - 用
DESCRIBE table_name快速扫一遍哪些列允许NULL，重点评估它们是否真有必要
行偏移不是玄学指标，它直接换算成每页少存几条记录、B+树多一层、一次查询多读几个页——这些在千万级数据下都会变成可测量的延迟。调优时盯着Avg_row_length和Innodb_buffer_pool_reads两个值，比看CPU使用率更能定位I/O卡点。
