mysql二级索引叶子节点存主键值而非物理地址，根本原因是innodb聚簇索引架构下，主键作为稳定逻辑标识可避免页分裂导致的地址失效与索引维护开销，同时兼顾一致性、存储效率及mvcc兼容性。
二级索引叶子节点存的是 主键值，不是磁盘偏移量
InnoDB 的二级索引（比如 CREATE INDEX idx_email ON user(email)）在 B+ 树叶子节点中存的永远是 email 字段值 + 对应行的 主键值（如 id=123），而不是该行在 .ibd 文件里的物理页号或页内偏移。这是因为 InnoDB 的数据组织方式决定了：数据只真实存在于聚簇索引（即主键索引）的叶子页里，其他索引只是“找主键的跳板”。一旦用物理地址，就等于把索引和数据的物理位置强绑定——而 InnoDB 的页分裂、页合并、数据迁移等操作会让物理位置频繁变动。
物理地址会随页分裂失效，主键值却始终稳定
当一条记录更新导致所在数据页满载时，InnoDB 会触发页分裂：原页拆成两个，部分记录被移到新页。此时，原页内某些记录的物理地址（如 page_no + offset）就彻底作废了。如果二级索引存的是这类地址：
- 所有指向这些记录的二级索引项都得同步更新，否则查询会读到错误数据或报错
- 一次 UPDATE 可能引发多个二级索引的随机写入，IO 放大严重
- 并发写入下还要加额外锁来保护地址一致性，吞吐下降
而 主键值（尤其是自增 BIGINT 或 INT）是逻辑标识，不随物理位置变化。页分裂后，只要主键没变，二级索引完全不用动——维护成本从“全量重写”降为“零更新”。
存储 主键值比存物理地址更省空间、更易压缩
物理地址通常需固定长度表示，例如 8 字节的 page_no + offset 组合；而主键可设计得更紧凑：
- 用
INT UNSIGNED（4 字节）代替VARCHAR(36)UUID 主键，单个二级索引项直接少存 32 字节 - 一张表若有 5 个二级索引，每个索引每百万行就节省约 15MB 存储（5 × 10⁶ × 32B）
- InnoDB 的页内键值排序和前缀压缩对短整型主键更友好，进一步降低 B+ 树层级
反过来说，如果主键本身很长（比如 36 位 UUID），那二级索引体积膨胀就是实打实的成本——这时候不是“为什么存主键”，而是“为什么选这么长的主键”该被质疑。
回表是必然代价，但 覆盖索引能绕过它
存主键带来的直接后果是“回表”：查 SELECT name FROM user WHERE email = 'a@b.c' 可以走 idx_email 覆盖索引；但查 SELECT phone FROM user WHERE email = 'a@b.c' 就必须先拿到 id，再二次搜索聚簇索引。这不是缺陷，而是权衡：
- 避免物理地址失效风险
- 统一用主键做跳转，MVCC、事务可见性判断都基于主键+事务ID，逻辑一致
- 覆盖索引（
index covering）是明确鼓励的优化手段，建索引时把常用查询字段包含进去即可
真正容易被忽略的点是：**主键越长，回表成本越高，覆盖索引收益越低**。别只盯着“有没有索引”，得看 WHERE 条件字段 + SELECT 字段组合后，能否让二级索引叶子节点存下全部所需内容。
