非聚簇索引叶子节点存储索引列值和完整主键值（或隐式row_id），用于回表查询；主键越长索引体积越大、性能越差；等值查询时按主键值二次排序以保证有序性。
MySQL InnoDB 中，非聚簇索引（也叫二级索引、辅助索引）的叶子节点不存整行数据，只存两样东西：索引列的值 和 对应记录的主键值。
主键值是精确存储，不是地址或偏移量
这个主键值是真实、完整的主键字段内容，比如主键是 BIGINT 类型的 id=100005，那叶子节点就原样存 100005；如果是联合主键（如 (order_no, version)），就完整存这两个字段的组合值。它不是物理地址、行号，也不是页内偏移——InnoDB 靠这个值再去聚簇索引里精准定位数据行。
没有显式主键时，用隐式 ROWID 替代
如果表没定义主键，且也没有合适的 NOT NULL UNIQUE 列，InnoDB 会自动生成一个隐藏的 6 字节 row_id 作为聚簇索引键。此时，所有非聚簇索引的叶子节点存储的就是这个隐式 row_id，逻辑完全一致：先查索引得 row_id，再拿 row_id 去聚簇索引查数据。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
主键值长度直接影响索引体积和性能
主键越长，非聚簇索引占用空间越大，因为每条索引记录都要重复存储一遍主键值。例如：
- 用 UUID（CHAR(36)）作主键 → 每个非聚簇索引项多存 36 字节，B+ 树层级更深、缓存效率下降
- 用自增 INT（4 字节）作主键 → 索引更紧凑，回表路径更短，更适合高并发写入
主键值在叶子节点中参与排序与查找
非聚簇索引 B+ 树的排序依据是索引列本身（如 name），但同一索引列值下若有多条记录，InnoDB 会按主键值进一步排序（避免歧义，也利于范围扫描）。这意味着：叶子节点内部既按索引列有序，又在等值区间内按主键有序——这对某些 LIMIT + ORDER BY 场景有优化意义。
