MySQL中INT类型实际占用4字节还是8字节？InnoDB表行存储大小计算与实际不符的原因排查

嘿，我来帮你理清这个InnoDB存储大小的疑惑——你之前的计算只考虑了定义的列本身的存储，却漏掉了InnoDB行存储里的关键额外开销，这就是问题的核心！

一、InnoDB默认Compact行格式的固定行开销 #

MySQL 5.7默认使用Compact行格式，这种格式下每一行除了你定义的字段，还包含以下强制开销：

• 事务ID（TRX_ID）：6字节，用于MVCC事务版本管理
• 回滚指针（ROLL_PTR）：7字节，指向回滚段中的undo日志，支持事务回滚和读一致性
• 行头（Row Header）：5字节，存储行的状态标记（如是否被删除）、字段数量等元信息

这三部分加起来就是 6+7+5=18字节 的固定开销。把你计算的列总大小（36字节）加上这部分开销：36+18=54字节。而InnoDB会对行数据做8字节对齐，54向上取整到最近的8的倍数就是56字节——这刚好和你实际计算的单行56字节完全匹配！

二、添加二级索引后的大小变化解释 #

你添加foreign_id_1_index后表总大小从268MB涨到340MB，这是InnoDB聚簇索引特性导致的：
InnoDB是聚簇索引引擎，主键id作为聚簇索引的核心，所有二级索引的叶子节点都会存储完整的主键值，用来关联到聚簇索引中的对应行。

对于你创建的这个二级索引，每个索引条目包含：

• 索引列foreign_id_1：4字节
• 主键列id：4字节
• 索引条目的精简行头开销：约5-6字节

每个索引条目大概占用14-15字节，500万行的话总索引大小约70-75MB，和你看到的72MB（340-268）增长基本一致。你计算的“单行占用从56到71”其实是把数据行和索引条目合在一起统计的结果，这也符合两者的开销总和。

三、关于NDB引擎隐藏主键的说明 #

你提到的NDB引擎隐藏主键的规则不适用于InnoDB：InnoDB只有在没有显式定义主键时，才会自动生成一个6字节的隐藏主键（GEN_CLUST_INDEX），而你已经显式定义了id作为主键，所以不会触发这个逻辑。

内容的提问来源于stack exchange，提问作者Vitaliy Vasilev