二级索引叶子节点存主键值是为了避免页分裂导致物理地址失效、降低维护开销，并保障mvcc与一致性；主键越短，二级索引体积越小、b+树层级越浅、缓存效率越高。
为什么二级索引叶子节点要存主键值？
InnoDB 的二级索引（非聚簇索引）不直接指向数据行的物理地址，而是存储对应记录的 PRIMARY KEY 值。查询时，先通过二级索引找到主键，再用该主键回表查完整数据——这个“回表”过程依赖主键值本身。所以主键不是只在主键索引里有用，它被**复制到每一个二级索引的叶子节点中**。
主键长度如何影响二级索引体积？
每个二级索引条目都多存一份主键。如果主键是 UUID（36 字符字符串，utf8mb4 下占 144 字节），那每个二级索引叶子节点就比用 BIGINT（8 字节）多出约 136 字节。这意味着：
- 同样一页（默认 16KB）能存的索引条目数大幅减少
- 索引树层级可能变深，增加 B+ 树遍历的 I/O 次数
- 缓冲池（
innodb_buffer_pool_size）中缓存的索引页更少，缓存命中率下降 - 范围扫描或
ORDER BY二级索引时，需读取更多页
自增整数主键为什么是默认最优解？
INT 或 BIGINT 自增主键满足三个硬性条件：窄（固定 4 或 8 字节）、单调递增、不可变。这带来直接效果：
- 插入时几乎不触发页分裂，写入是顺序 I/O
- 所有二级索引体积最小化，对内存和磁盘都友好
- 主键值小，比较和排序开销低，B+ 树内部节点分裂/合并更高效
- 外键引用时，关联字段也只需同样小类型，不额外放大索引
业务上真不能用 UUID 或复合主键吗？
可以，但代价明确：
-
UUID作为主键 → 所有二级索引膨胀 10 倍以上，尤其当表有多个二级索引时，空间和性能损耗呈倍数叠加 - 复合主键（如
(tenant_id, order_id)）→ 主键长度取决于字段总和，若其中任一字段可变长（如VARCHAR(255)），二级索引实际占用远超预期 - 补救方案有限：把
UUID存为BINARY(16)可减半体积，但仍远大于BIGINT；复合主键建议只在极少数分片或租户隔离强场景下权衡使用
真正容易被忽略的点是：主键长度的影响不是只作用于主键索引，而是**全局传染**到所有二级索引——哪怕你只建了一个 INDEX(status)，它也在默默复制你的主键值。优化主键，是最廉价、最底层、也最容易被绕过的性能杠杆。
